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ABSTRACT 



The formal specification language Spec is used for writing black-box specifications 
for large software systems. These black-box specifications describe the interface 
between a system and its users, as well as internal interfaces between modules. Systems 
analysts use specifications written in Spec to verify the customer’s requirements during 
the development of a software system. 

This thesis demonstrates the feasibility of designing and implementing a syntax 
directed editor for a subset of the specification language Spec. The editor is a software 
tool for writing Spec specifications that ensures syntactic correctness of such specifi- 
cations. The syntax directed editor is created using the Synthesizer Generator, a 
Computer-Aided Software Engineering (CASE) tool for generating language-based 
editors. The specification for the editor is written in the Synthesizer Specification 
Language (SSL) which is based on an attribute grammar. The software tool developed in 
this thesis supports the Requirements Analysis phase of the software development cycle. 
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I. INTRODUCTION 



A. OVERVIEW 

Spec is a formal specification language designed to write black-box specifications of 
software systems. These black-box specifications describe the interface between a 
system and its users as well as internal interfaces between modules. Specifications 
written in Spec are used by systems analysts to verify the customer’s requirements. The 
specification is then translated into an appropriate programming language (such as Ada) 
by programmers. 

Currently, Spec is a research tool with the potential to become an industry standard in 
software development. An eventual goal is to create an integrated environment of 
software tools for Spec. These tools would include an editor, type checker, consistency 
checker, inheritance expander, pretty printer, test oracle, diagram generator and a 
translator to Ada. 

A syntax directed editor is the primary tool of such an integrated environment. The 
user is guaranteed a syntactically correct Spec specification at the end of each editing 
session. By ensuring syntactic correctness as the specification is being designed/edited, 
the overall time spent designing the system is reduced. 

This thesis discusses the development of SPECDEF, a syntax directed editor for a 
subset of the Spec specification language. Chapter II gives a general description of a 
syntax directed editor and compares two primary editor generator systems. Chapter IH is 
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a description of the Spec language. The complete Spec grammar appears in Appendix A. 
Chapter IV details the concepts behind the Synthesizer Generator, design decisions, and a 
practical approach to designing a syntax directed editor specification. The specification 
files for the SPECDEF editor appear in Appendix B. A user’s manual for the SPECDEF 
editor appears in Appendix C, and a listing of all editor system commands appears in 
Appendix D. 

B. DESCRIPTION OF SOFTWARE ENGINEERING PRINCIPLES 

Computers are playing an increasingly large role in our lives. Many manufacturing 
processes are being automated, retail and grocery stores have computerized pricing and 
inventory systems, banks are providing automatic teller machines, travel agents make our 
plane reservations through computers, etc. In order for these and other computer systems 
to perform useful tasks, reliable and efficient software is required. 

Software engineering applies scientific and mathematical principles to the develop- 
ment of software in order to make computers useful to people. Software consists of the 
actual programs, all documentation and user’s guides, operating procedures and test cases 
that are associated with a computer-based system. A primary goal of software engi- 
neering is the development of effective scientific methods for producing software that 
meets the customer’s schedule and budget constraints while satisfying all his require- 
ments for the software system. [Ref. 1] 

Computers can perform tasks that are repetitious, too time consuming, or too 
complicated for people to do manually, and they can usually perform those tasks faster, 
with greater reliability, more efficiently and at a lower cost than people can. In order for 
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computers to be useful, the software system designed for the customer must be able to 
perform all functions required by the user in a correct and efficient manner. Any failure 
of the system to operate correctly could be costly in terms of lives, equipment, and 
money. Software systems should not only be "correct", i.e., conform to the specification, 
but also should perform the functions desired by the customer. Correct but inappropriate 
systems are sometimes built because the software developers did not understand the 
user’s needs, or the software cannot adapt to changes in those needs. [Ref. 1] 

Hardware prices have decreased by about 50% roughly every two years. This in turn 
has triggered a demand for larger, more sophisticated computer applications. It is 
impossible for a single person to understand or to build large and complex software 
systems. Therefore, a software development organization is needed. The system must be 
organized as a set of modules that are small enough to be developed by a single person. 
Each of the developers in the organization must communicate with the other developers, 
either directly or through documentation. This documentation must be precise so that all 
developers on the project team have a complete and correct under-standing of the 
interface between the module(s) they are developing. In addition to this formal 
documentation, communication is extremely important, particularly in large projects, 
where project members come and go. [Ref. 1] 

The software development process consists of a cycle of qualitative activities: 
requirements analysis, functional specification, architectural design, implementation, and 
evolution. The development will proceed most efficiently if these activities are per- 
formed in a pipeline fashion. However, each activity does not necessarily end when the 
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next begins. Often, insights are gained at later stages that trigger modifications or 
extensions to earlier results. Therefore, feedback is essential. The relationship between 
activities of the software development cycle is illustrated in Figure 1. 

Requirements analysis is the process of determining and documenting the customer’s 
needs. The purpose of the system, as well as any constraints on its development, is 
determined at this stage. A systems interface is proposed and formalized in the 
functional specification stage. This interface only describes those aspects of the system 
behavior that are visible to the user or to other external systems. The system is then 
decomposed into modules in the architectural design phase. Internal interfaces, i.e., those 
not visible to the user, are defined here. Implementation is the production of a program 
for each of the modules. The data structures and algorithms used within each module are 
defined here. Finally, the evolution, or repair process, allows for adaptation of the 
system to changing needs of the customer. Any discrepancies between the specification 
and the implementation that are discovered after system delivery are repaired here, and 
the capabilities of the system are expanded as new requirements are discovered. This 
evolution requires repeating the previous four steps of the software development cycle. 
[Ref. 1] 

The SPECDEF editor will be useful mostly in the requirements analysis phase of the 
software development cycle, and to a lesser extent in the functional specification and 
architectural design phases. 
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Software Development Cycle 



Thorough analysis and testing of each module is absolutely necessary if a "correct" 



system is to be developed. A project database should be utilized to record and distribute 



all information about the state of the development process. This database will contain a 



variety of documents, including the requirements, designs, justifications for those 



designs, the code, test cases and results, user’s manuals, the schedule of the development 



project, work assignments, etc. The larger the system, the larger the database, and the 



greater the need for a database management system. For engineering applications, a 



specialized engineering database system is required to efficiently manage the project 



database. This is a relatively new development, and mature systems are not yet widely 



available. Future versions of SPECDEF should interface to this design database. [Ref. 1] 
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C. COMPUTER-AIDED SOFTWARE ENGINEERING (CASE) 

The time spent in the requirements analysis, functional specification and architectural 
design stages of the software development cycle has been greatly reduced by the 
advancements made in computer-aided software engineering (CASE) tools. These tools 
assist the systems analyst and software engineer in specifying the system’s requirements 
and design. Many of the design and development problems inherent in medium to large 
software projects are reduced or eliminated by the use of CASE tools. [Ref. 2] 

Some CASE tools can automatically generate code from the software design 
specification. Two benefits are achieved from this. First, the implementation time is 
substantially reduced since the code (or at least part of it) is being generated automa- 
tically. Secondly, the software engineer may feel more confident about the quality of the 
generated code because it was produced by a software tool that has itself been thoroughly 
tested and debugged. [Ref. 2] 

Truly generalized code generation is not available in any of today’s general-purpose 
tools. However, specialty development tools that focus on a particular type of software, 
such as user interface design tools, are available that will generate code. This thesis will 
discuss the use of one such tool, the Synthesizer Generator, which generates a syntax 
directed editor program. This generated program is in fact another example of a CASE 
tool. 

In general, CASE tools are designed to increase the productivity of systems analysts 
and software engineers. Many of these tools are actually requirements and design 
specification editors that provide output in specific formats, often graphically oriented, 
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that can be read and understood by end-users and developers alike. They eliminate the 
drudgery of drawing and redrawing data flow diagrams, module hierarchy charts, etc., 
that often change as the project development proceeds. Time is saved and formats are 
consistent. Future versions of the SPECDEF editor should interface with tools for 
generating such diagrams and other summary information. [Ref. 2] 

D. FOURTH-GENERATION LANGUAGES 

The term "fourth-generation language” can be looked at in two different ways. Some 
authors use the term to refer to application generator programs. Applications generators 
are software tools that take a design specification as input and produce compilable code 
as output When used in this context, the "fourth-generation language" in not always a 
programming language in the sense that a programming language is intended to describe 
a program [Ref. 3]. This context includes many CASE tools, such as program generators. 
Fourth-generation languages in this context are sometimes thought of as higher-level 
focused languages that provide mechanisms for accessing data bases [Ref. 2], Many 
software professionals think of fourth-generation languages as a form of CASE [Ref. 2]. 

Other authors, when referring to "fourth-generation languages," mean a particular 
class of modem programming languages, including Ada. Fourth-generation 
programming languages provide mechanisms for data abstraction. An encapsulation 
facility supports the separation of the specification and definition of data structures, 
information hiding, and name access by mutual consent. A facility for passing messages 
between concurrent tasks to maintain synchronization and communication supports 
concurrent programming. [Ref. 3] 
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A software crisis developed in the mid 1970’s because software development had 
become labor intensive rather than a labor-saving activity. There were problems with 
responsiveness of computer systems to customers’ needs, reliability of software, escal- 
ating software development costs, maintainability of software systems, timeliness of 
development of software systems, transportability of software from one operating envi- 
ronment to another, and efficiency of the software in terms of processing time and 
memory space. Software systems were becoming increasingly larger and more complex. 
The most popular programming languages at that time, FORTRAN and COBOL, did not 
reflect newly developed software engineering principles and were not suitable for 
embedded computer systems. An embedded computer is one that is a component of a 
larger system, e.g., a guidance computer on a missile, or a target tracking computer in a 
weapon system, etc. [Ref. 4] 

The United States Department of Defense (DoD) recognized this software crisis. 
There was no standardization in DoD projects as far as programming languages were 
concerned. In response to these problems, DoD commissioned a worldwide language 
design competition with the goal of developing a single high-order language suitable for 
use in embedded computer systems as well as conforming to other well-defined require- 
ments. The result of that competition was Ada. It is designed specifically for large, 
software-intensive, real-time embedded computer systems. However, it is suitable for 
other application areas as well. Ada both embodies and enforces modem software 
engineering development principles, such as structured constructs, information hiding. 
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and abstraction. Ada is now a prime language in the computing industry, as well as being 
the required language for embedded computer systems in DoD projects. [Ref. 4] 

Both viewpoints on the definition of a fourth-generation language are applicable to 
this thesis. In the first sense, that of an application generator, the Synthesizer Generator 
is a CASE tool that takes as input an editor specification written in a fourth-generation 
language and outputs compilable C code, which is then compiled into an executable 
editor program. In the second sense, that of a class of programming languages, the 
purpose of the editor produced by the Synthesizer Generator is to support the early stages 
of software design for eventual translation in to a fourth-generation language, specifically 
Ada. 
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H. BACKGROUND 



A. GENERAL DESCRIPTION OF A SYNTAX DIRECTED EDITOR 

A syntax directed editor is a software tool for creating or modifying programs in such 
a way that correct syntax is always maintained. It will not allow syntactically incorrect 
constructs to be entered. Generally, the editor is designed for one specific programming 
language, although editors exist that allow different languages to be programmed into it. 
Often, the editor is the prime component of a set of programming tools that make up an 
integrated programming environment. 

Most syntax directed editors are screen-based, i.e., program text is entered at the 
location indicated by the display cursor, and the screen display is automatically updated, 
just as most text editors do. But text editors, as the name implies, only allow modifi- 
cation of the text, whereas syntax directed editors allow modification of the syntactic 
structure of the program, as well as the text itself. As the text is entered, it is checked for 
syntactic correctness, and errors are immediately detected and appropriate messages 
displayed to the user. This prevents the user from writing programs that are syntactically 
incorrect. [Ref. 5,6] 

In most syntax directed editors, text is entered by creating a template, or a skeleton, 
of some syntactic construct, and filling in the detail later. These templates form a parse 
tree and only allow syntactically correct constructs to be generated. The user selects a 
node of the parse tree that contains a non-terminal to fill in the detail. This non-terminal 
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can be expanded into valid syntactic alternatives. Some editors will display a list a valid 
choices for the current node. The user can also enter directly the desired text, and if the 
entry is not syntactically correct, the editor will then display a list of alternatives to the 
user. This process, known as programming by selection, is partic-ularly beneficial in a 
learning environment because the time to learn the rules of the language (the syntax) is 
reduced. Figure 2 is an example of the programming by selec-tion process for a 
compound statement using an arbitrary language. [Ref. 5,6] 



Program Statement Transformation Selected 

begin <stmntlst> end 

<stmntlst> > <stmntlst>\ <stmnt> 

begin <stmntlst>\ <stmnt> end 

<stmntlst> ><stmnt> 

begin <stmnt>\<stmnt> end 

<stmnt> > <assign_stmnt> 

begin <assign_stmnt>\ <stmnt> end 

<assign_stmnt> >x 5 

begin x 5; <stmnt> end 

<stmnt> > <proc _call> 

begin x := 5; <proc_call> end 

<proc_call> > p(x) 

begin* := 5; p(x) end 



Figure 2 

Programming by Selection 

Since visual display units (VDUs) generally can only display 24 lines of text at a 
time, it is impossible to display much of the parse tree graphically on the screen. How- 
ever, an overall view of the program (or at least a larger portion of it) is possible by 
unparsing the tree, i.e., displaying text down to a certain level of detail and omitting the 
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remaining detail. The omitted portions are commonly replaced by ellipses so the 

overall view of the structure remains intact. The user may then select a particular portion 
on which to zoom in and display greater detail. [Ref. 5] 

Changes are made to the structure of the program using the central commands of the 
editor. The editor might allow changes in terms of operations on the branches of the 
parse tree, by matching subtrees and substitution, or by entering arbitrary text and repar- 
sing the tree. For example, suppose the user wanted to rename a variable "red" to "blue". 
Variables are a construct of the language, i.e., a subtree. Changing the symbol of this 
subtree from "red" to "blue" does not affect other text strings in the parse tree that contain 
the substring "red", i.e., a variable "fred" is not changed to the variable "fblue". This 
kind of structural editing (as opposed to simple text editing) avoids unintended changes 
to the program. If this were not the case, i.e., if such a substitution replaced every 
instance of the substring "red" throughout the program, the result would be potentially 
disastrous. [Ref. 5] 

Structural commands insert, copy, move and delete subtrees within the parse tree. 
Subtrees can also be clipped, or contracted into a non-terminal symbol of the grammar. 
These clipped pieces are saved, and can be reused at other locations using a special form 
of the insert command. The benefit of this facility is the time saved by copying or 
moving whole subtrees from one location in the parse tree to another rather than having 
to re-construct the subtree at the new location. [Ref. 5] 
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Most syntax directed editors incorporate a pretty-printing function. This can be 
reflected on the display screen as well as on the hardcopy output Pretty-printing might 
be a selectable function, or it might be done automatically. [Ref. 5] 

A syntax directed editor can also maintain some semantic constraints. For example, 
every variable that is used must be declared. Such facilities are useful for preventing 
some classes of errors. 

The SPECDEF editor incorporates some of the facilities mentioned above. It is a 
screen-oriented hybrid editor that modifies the structure of the edited object by template 
insertion as well as direct text entry. The valid choices for template insertion are 
displayed to the user at each node of the parse tree when that node is selected. Textual 
changes to one construct do not affect the same text in other constructs. Subtrees can be 
clipped and copied or moved to other locations in the parse tree. Pretty-printing is 
automatic in the sense that indentation and line breaks are designed into the unparsing 
schemes. 

SPECDEF does not, however, have any provisions for semantic checking of variable 
declarations or for elision of detail into ellipses. Future versions of SPECDEF will be 
integrated with a type checker and a consistency checker that will help maintain semantic 
constraints. Provisions for elision of detail may also be incotporated in future versions of 
the SPECDEF editor. 

B. SYNTAX DIRECTED EDITOR GENERATORS 

An important area of research in computer science is that of language-based 
programming environments. Probably the most significant programming tool in such an 
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environment is a syntax directed editor. Integrating a syntax directed editor with 
execution and debugging facilities creates a powerful programming tool. Several such 
systems have been developed, e.g., GANDALF [Ref. 7,8], and the Cornell Program 
Synthesizer [Ref. 9]. The Synthesizer Generator [Ref. 10,11] is an outgrowth of the 
Cornell Program Synthesizer. 

Both GANDALF and the Synthesizer Generator have the capability to create editors 
for languages other than programming languages, such as verification languages or 
specification languages. The Synthesizer Generator was selected as the primary tool for 
this thesis because of the availability of mutual support with a parallel research project in 
prototyping languages currently under development at the Naval Postgraduate School. 
Also, at this stage of research, there was not a need to generate a multiple user environ- 
ment such as GANDALF generates. The discussion on GANDALF is offered for 
purposes of comparison. Follow-on research to this thesis may wish to investigate the 
use of GANDALF to create a multiple user environment. 

1. The GANDALF System 

The GANDALF System is a softw-are tool that generates integrated environments 
that are language-specific. Two different kinds of environments are possible using this 
system -programming environments and software development environments. A 
programming environment is a highly interactive knowledge-based environment for a 
single programmer working on a small project. A software development environment, 
which is the primary purpose of the GANDALF project, is one in which multiple 
programmers work on large projects. [Ref. 8] 
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The heart of the GANDALF project is designed around the ALOE editor 
generator system, which stands for A Language Oriented Editor. A language oriented 
editor is also known as a syntax directed editor or a structure editor in the literature. 
ALOE is actually the common kernel that is used by all syntax directed editors generated 
with this system. A specific instantiation of a syntax directed editor is known as an 
ALOE editor. ALOEGEN is an ALOE editor that is used to create the syntactic 
descriptions of a language that can then be used in conjunction with ALOELIB, which is 
library support to add semantic actions and additional commands, to create a syntax 
directed editor for the specific language. [Ref. 7] 

The user interface of all generated ALOE editors are tree-oriented full-screen 
interfaces. There is a set of language-independent commands, such as subtree deletion 
and cursor motion, as well as a set of language-specific operations that represent 
structures of the language, such as Pascal while statements or Ada packages. [Ref. 7] 

As a programmer creates or edits a program with an ALOE, the program is 
displayed much the same way as a text editor would display it. But the representation is 
based on the structure of the program rather than simply as a string of characters. This 
structure is an abstract syntax tree. The programmer moves about the program by way of 
this tree structure. The cursor will highlight an entire structural unit, such as a Pascal if- 
then-else construct, or a specific non-terminal within the structural unit, rather than just a 
single character. Operations are performed on the structure of the program, i.e., insertion 
or deletion of structural units, or expansion of non-terminals. [Ref. 8] 
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As stated earlier, the primary focus of the GANDALF project is the generation of 
software development environments that would support multiple programmers working 
on a large project. This type of environment also has an ALOE editor as its basis, but in 
addition provides a system version control editor and a project management editor to 
solve programming-in-the-large and programming-in-the-many problems respectively. 
These problems are significantly harder to solve because of the interaction required 
between various modules developed by different programmers on the team. Research is 
continuing in this area. [Ref. 8] 

2. The Synthesizer Generator 

The Synthesizer Generator is a system that creates a language-specific editor from 
a specification of the language’s abstract syntax, context-sensitive relationships, display 
format, concrete input syntax, and transformation rules for restructuring objects. The 
specification language for the Synthesizer Generator, SSL (for Synthesizer Specification 
Language), is based on the concept of an attribute grammar. An attribute grammar is an 
extension of a context-free grammar. The extensions are the attributes which have been 
attached to the nonterminal symbols. The value of these attributes is defined by attribute 
equations. This mechanism can specify how widely separated parts of a derivation tree 
can be constrained by the context of the rest of the tree. [Ref. 10] 

Specifications written in SSL are different from specifications written for other 
systems that are based on attribute grammars. This is because SSL has several 
innovations, e.g., the capability to merge abstract-syntax definitions and user-defined 
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attributes, a notation that allows specifications to be broken into separate modules, and 
the manner in which the parser is incorporated into the system. [Ref. 10] 

There are two basic components that comprise the Synthesizer Generator: (1) a 
translator that converts SSL specifications into various tables as output, and (2) an editor 
kernel with an attributed-tree data type and a driver for manipulating attributed trees 
interactively. The kernel executes operations on the current tree according to keyboard 
and/or mouse commands. A shell program named sgen invokes the translator and pro- 
duces the syntax directed editor for the specified language from the tables that are output 
from the translator. [Ref. 1 1] 

Objects being edited with an editor produced by the Synthesizer Generator are 
represented as attributed derivation trees. Each modification to the object being edited 
causes the attribute values throughout the tree to be updated. If a modification results in 
the violation of any context-dependent constraints, the display is annotated with error 
messages to provide the user with immediate feedback. [Ref. 11] 

The editor produced by the Synthesizer Generator displays constructs of the 
language as templates, or predefined, formatted patterns. Non-terminals within 
constructs can be thought of as placeholders where additional insertions can be made 
through a transformation equation. When the user selects a subterm (i.e., a placeholder) 
a menu of possible transformations is listed. A transformation is invoked either by 
typing the name or making a menu selection with a mouse. Transformation definitions 
are type-checked when the SSL specification is compiled into an editor, so it is 
impossible for a transformation to introduce context-free syntax errors. [Ref. 1 1] 
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In addition to the transformations, which are language specific, every editor 
generated by the Synthesizer Generator contains language independent system commands 
such as cut-to-clipped and paste-from-clipped. The cut operation differs from ordinary 
text editors, which would delete the selected text and leave the cursor at that position. In 
the syntax directed editor, the cut operation replaces the selected subterm with a place- 
holder, thus maintaining the correctness of the context-free syntax. The paste operation, 
conversely, replaces the placeholder term with the previously cut subterm.[Ref. 1 1] 

The Synthesizer Generator is written in C and runs under the Berkeley UNIX 
system. Editors can be generated for specific windowing systems, such as VIDEO, SUN, 
and X-Windows. There are a number of selectable options when invoking sgen that 
affect the method of generation and the capabilities of the generated editor. For a 
complete list of these options, refer to Appendix B of [Ref. 11]. 
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m. AN OVERVIEW OF THE SPEC SPECIFICATION LANGUAGE 



A. THE PURPOSE OF SPEC 

The functional specification stage of the software development cycle gives a black- 
box specification of the software project, i.e., only the interface between modules is 
described, not the inner workings. Spec is a formal language for writing such black-box 
specifications, as well as for specifying the internal interfaces of the proposed system 
during the architectural design phase. [Ref. 12] 

A precise, formal specification of a proposed software system is essential in order to 
ensure that everyone on the development team understands and agrees with the interpre- 
tation of the user’s requirements. Programming languages, such as Ada, are formal, but 
because they are designed for describing algorithms and data structures rather than the 
actual behavior of a module, they are not suited for writing black-box specifications. 
Spec is designed specifically for defining the behavior of software modules. The formal 
notation of Spec provides the precision needed to prevent the ambiguity inherent in 
English and other informal notations. [Ref. 12] 

Spec uses the event model to define the behavior of a proposed system. The event 
model describes computations in terms of modules, events and messages. 

A module is a black box that interacts with other modules only by sending and 
receiving messages. An event occurs when a message is received by a module at a 
particular instant of time. A message is a data packet that is sent from one module 
to another. (Berzins, 1987, p. 2) 
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Modules can model either software components, or external systems such as peripheral 
hardware or even the user. Messages are accepted by a module one at a time. The length 
of a message is arbitrary. It is assumed that every message sent eventually arrives at its 
destination. [ Ref. 1] 

The sequence of messages that are received by a module determine what kind of 
response will occur. Modules are classed as mutable or immutable depending on how 
the module reacts to messages. If the response of the module can depend on one or more 
messages received prior to the most recently received message, the module is mutable. 
Mutable modules behave as if they had internal states or memory. If the module’s 
response to every possible message depends solely on the most recently received 
message, the module is immutable. A module is immutable if and only if it is not 
mutable. Immutable modules behave more like mathematical functions. [Ref. 12] 

B. MODULE DESCRIPTIONS 

Five types of modules can be specified in Spec: definitions, functions, state 

machines, abstract data types, and instances of generic modules. 

1. Definition Modules 

Definition modules contain descriptions of concepts that are not unique to any 
particular function, machine, or type declaration, but are instead available to be shared 
among many modules through importation. Only concepts may be declared in definition 
modules. Definition modules may also import other modules. [Ref. 1] 

Concepts describe the logical assertions that define the behavior of modules. 
They can define constant symbols, symbolic type names, predicates (relationships) and 
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functions (attributes). These conceptual representations are introduced by the keyword 
CONCEPT. Concepts can be explicidy exported to other modules through an EXPORT 
clause, as well as imported from other modules through an IMPORT clause (provided it 
has been explicidy exported from the module in which it is defined). [Ref. 1] 

Definition modules form the primary subset of the requirements analysis phase of 
the software development cycle. In requirements analysis, a model of the problem 
domain is created to record facts about the problem and the environment of the proposed 
system needed by the developers in later stages. These facts are represented as concepts 
contained in definition modules. The SPECDEF tool developed in this thesis treats the 
subset of the Spec language used in this process. 

2. Function Modules 

Function modules are one of the three primary module types in Spec (the others 
being machine modules and type modules). A function module behaves like a 
mathematical function in that it calculate the value on a data type. [Ref. 12] 

A function usually will perform only one task or service, so they will only accept 
anonymous (i.e., unnamed) messages. Messages in a function module define the 
"operations" that the function may perform. They are introduced by the keyword 
MESSAGE. [Ref. 1,12,13] 

Each message, or operation, returns a value in the form of a REPLY message. A 
variety of responses can be defined with WHEN clauses, which specify preconditions 
similar to the Pascal case statement or the switch statement in C. If none of the WHEN 
clauses apply, an OTHERWISE clause handles the remaining cases. If a message 
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response is to report an abnormal condition, a REPLY EXCEPTION message is returned. 
Postconditions that must be satisfied by the outgoing message are specified with a 
WHERE clause. [Ref. 1,12,13] 

To illustrate the above concepts. Figure 3 depicts a function / that accepts an 
anonymous message consisting of an input variable of type typel. If the input variable 
satisfies precondition easel , the returned value is the output variable of type2 , with a 
postcondition that must also be satisfied. If the input variable satisfies precondition 
case2, an abnormal situation exists, so the returned value is the exception failure 1. If 
neither of the preconditions can be met, then the OTHERWISE clause takes effect and an 
exception failure2 is returned. 



FUNCTION/ 

MESSAGE (input-var : typel) 

WHEN easel (input-var) 

REPLY (output-var : type2) 

WHERE postcondition (output-var, input-var) 
WHEN case2 (input-var) 

REPLY EXCEPTION failure 1 
OTHERWISE REPLY EXCEPTION failure2 

END 



Figure 3 

Example of a Function Module 



3. Machine Modules 

Machines are mutable modules that have an internal state. The conceptual model 
of that state describes the behavior of the module, rather than the messages received in 
the past. The keyword STATE introduces the declaration of the components of the 
conceptual model of the state, and any restrictions on the set of meaningful states are 
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given in an INVARIANT clause. Restrictions on the initial state are given in an 
INITIALLY clause. Input stimuli to the machine which invoke actions are defined in 
MESSAGE clauses. The actions can be any combination of a REPLY, a REPLY 
EXCEPTION, one or more SEND statements, or a TRANSITION to a new state. 
Transitions are given as equations that describe the change either forwards or backwards 
in time, whichever is simpler (i.e., in terms of the state before the transition or in terms of 
the state after the transition). Messages can be sent to modules other that the origin of the 
incoming message. This is done using a SEND statement instead of a REPLY. There 
can be any number of SEND statements, but only one REPLY statement. [Ref. 1,12,13] 
The example in Figure 4 depicts a machine called buffer which has a state model 
consisting of a single-valued state-var of type typel. The statements INVARIANT true 
and INITIALLY true indicate there are no restrictions on the states of the machine. If the 
stimulus read is sent to the machine, the reply is the current value of state-var. If the 
stimulus update is sent with the parameter new-value of the type typel, the state of the 
machine is changed by assigning the new-value to state-var. When the transition is 
complete, the reply message done is sent to the initiator of the stimulus. 
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MACHINE buffer 

STATE ( state-var : typel) 

INVARIANT true 
INITIALLY true 

MESSAGE read 

REPLY (result : type 1) 

WHERE result = state-var 

MESSAGE update (new -value : typel) 

TRANSITION state-var = new- value 
REPLY done 

END 



Figure 4 

Example of a Machine Module 

4. Type Modules 

Abstract data types are defined in type modules. An abstract data type consists of 
a set of values and a set of primitive operations that operate on those values. In the type 
module, each operation is represented by a named message. The data type is described in 
terms of a conceptual model rather than the actual data structure used in the implemen- 
tation. The implementation of the data type can change to improve performance, but the 
conceptual model will still be valid. The keyword MODEL introduces the tuple that 
represents each instance of the data type. The components of the tuple can have 
restrictions specified in an INVARIANT clause. The effects of the operations can be 
described by CONCEPT clauses. Type modules can be either mutable or immutable. 
[Ref. 12] 
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5. Instance Modules 



An instance module is used to make an instance or partial instantiation of a 
generic module. This is useful for renaming concepts in other modules before importing 
or inheriting them. For example, if module m contains a concept c that you wish to 
import, but you have already defined a local concept using the same name and argument 
types but with a different meaning, one of the two concepts will have to be renamed. If 
the name you have chosen for your local concept is a good one, then it is better to rename 
the imported concept. To do this, you must first create a new instance of module m, say 
new-m, in which you declare a renaming of concept c to new-c. The renamed concept 
can now be imported from the new instance of module m (i.e., module new-m). This 
example is illustrated in Figure 5. 

INSTANCE new-m = m 

RENAME c AS new-c 

END 

— The renamed concept can now be imported as follows: 

IMPORT new-c FROM new-m 



Figure 5 

Using an Instance Module to rename a concept 

C. OTHER FEATURES 

1. Concepts used as Subprograms 

Concepts, which were briefly described above, are of great benefit in simplifying 
descriptions of complex software systems. Long expressions in predicate logic, for 
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example, can be decomposed into several concepts that are easily understood individ- 
ually, making the overall expression more understandable. Concepts in Spec are 
analogous to subprograms in a programming language. 

2. Inheritance in Spec 

Spec has an inheritance mechanism that allows constraints that are common to the 
interface of several modules to be specified. This is particularly useful in specifying 
large software systems because it helps achieve a consistency in the interface of several 
modules. [Ref. 12] 

Inheritance applies to entire modules. An inherit clause is introduced with the 
keyword INHERIT followed by the name of the module being inherited. The effect is 
the same as if all the concepts, messages, models or states of the inherited module were 
copied verbatim into the current module. Any specific concept, message, model or state 
may be excluded from being inherited into the current module through a HIDE clause. 
To avoid name conflicts, messages or concepts can be "renamed" to a "new" name with a 
RENAME clause. [Ref. 13] 

There are restrictions on which type of modules can be inherited by which other 
types of modules. Definition modules may only inherit other definition modules. 
Function modules may inherit other functions and definition modules. Machine modules 
may inherit other machines, function modules and definition modules. Type modules 
may inherit other types, function modules and definition modules. Any of these four type 
of modules may inherit an instance module provided the base module that the instance 
instantiates is of a type appropriate to the module that is doing the inheriting. [Ref. 13] 
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A more detailed discussion of inheritance in Spec can be found in [Ref. 13]. 
Closely related to inheritance is the mechanism for importing and exporting 
concepts from one module to another. Only CONCEPTS may be imported and exported. 
An IMPORT clause is used to allow concepts defined in other modules to be made a 
"part of' the current module. An EXPORT clause allows concepts defined in the current 
module to be available for explicit importation into other modules. A concept cannot be 
imported unless it has been explicitly exported by the module in which it is defined. This 
importation and exportation mechanism, as well as the inheritance mechanism, is useful 
for logical grouping of related concepts into a single module in support of a modular 
construction of large software systems. [Ref. 1,12,13] 

The SPECDEF editor is able to declare INHERIT, IMPORT, and EXPORT 
clauses for definition modules. However, there is no capability for checking that the 
named module in an INHERIT clause exists, or whether a concept named in an IMPORT 
clause has been EXPORTed by the named module. It is therefore up to the user to ensure 
that such is the case. 

D. COMPLETE DESCRIPTION OF SPEC 

The foregoing discussion on Spec is necessarily brief. For a more thorough 
description see [Ref. 12] and Chapter 3 of [Ref. 1]. The grammar of the Spec language is 
included at the end of this thesis as Appendix A. 
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IV. DESIGN OF THE SYNTAX DIRECTED EDITOR FOR SPEC 



A. GOALS 

1. Short Term 

The initial short term goals for this research project were as follows: (1) gain an 
understanding of how to write a specification for a syntax directed editor in terms of the 
Synthesizer Generator specification language, SSL, and (2) implement a working model 
of the syntax directed editor for a subset of Spec. In order to achieve these goals as 
quickly as possible, it was decided to limit the specification to syntax editing only and 
forego any semantic checking. 

2. Long Term 

The long term goals (beyond the scope of this thesis) are to (1) implement the 
editor for the complete Spec grammar, and (2) integrate the editor into a complete 
programming environment for Spec. This environment will include the editor, a type 
checker [Ref. 15], a pretty printer [Ref. 16], a consistency checker, an inheritance 
expander, a test oracle, a diagram generator, and translator to Ada. With the exception of 
the pretty printer and an initial version of both the editor and the type checker, the tools 
mentioned above have yet to be developed. 

B. CONCEPTS FOR USING THE SYNTHESIZER GENERATOR 

To effectively utilize the Synthesizer Generator, several terms and concepts that are 
perhaps unfamiliar to most readers must be understood. An SSL editor specification is 
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built around three different but related grammars: the abstract syntax grammar, the 
concrete syntax grammar, and the unparsing scheme. The abstract syntax defines the 
basic set of context-free grammar rules that define the language, excluding any keywords 
in context (hence, context-free). The concrete syntax defines the input grammar for text 
entry, and the productions of this grammar do take keywords into account. The 
unparsing scheme defines the formatting rules for the display representation of the 
language, including keywords, punctuation, and indentation. [Ref. 10,11] 

1. Attribute Grammar 

The Synthesizer Generator is based on the concept of an attribute grammar. As 
mentioned previously, an attribute grammar is a context-free grammar that is extended by 
attaching attributes to the nonterminal symbols of the grammar and by defining attribute 
equations that determine the value of those attributes. Each attribute is a piece of 
information that describes some semantic property of the nonterminal. For example, a 
variable could have attributes such as type, value, length, etc. Each production in the 
grammar can have a set of attribute equations. 

There are two disjoint sets of attributes of a nonterminal: synthesized attributes 
and inherited attributes. Synthesized attributes are associated with the left-hand-side 
nonterminal of a production, while inherited attributes are associated with nonterminals 
of the right-hand-side of a production. That is, the left-hand-side synthesizes its attribute 
values from the right-hand-side attributes, and the right-hand-side inherits its attribute 
values from the left-hand-side attributes. [Ref. 10: p. 39] 
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The current version of the SPECDEF editor defines only a synthesized attribute t 
for some nonterminals whose value is the text string entered to represent the nonterminal. 
Future versions of SPECDEF may incorporate attributes that pertain to error messages or 
other environmental factors related to type checking. 

2. Abstract Syntax, Phyla and Terms 

The underlying abstract syntax of the language is simply the set of grammar rules 
that define the language, excluding any keywords. In SSL, the abstract syntax consists of 
a set of productions of the form 
X 0 :op(X iX 2 ...Xk); 

where op is an operator name and each X, is a nonterminal of the grammar. Each of 
these nonterminals is the name of a phylum, and each phylum is the set of derivation trees 
that can be derived from the nonterminal. A phylum is a special kind of abstract data 
type. The derivation trees are known as terms. A term is an expression that applies a k- 
ary operator to k elements of an appropriate phyla. The SSL grammar rule acts the same 
as the context-free production: 

x 0 — >x,x 2 ...x k 

The operator serves to distinguish between rules that have right-hand-sides that are 
structurally identical but which may have different keywords in a concrete syntax. For 
example, the operator names Equal, Add, and Subtract in Figure 6 distinguish between 
three kinds of expression pairs. [Ref. 10: pp. 45-47] 
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root start: 


start : 


Spec(spec); 


optional list spec; 
spec 


ModuleNilQ 


1 


ModulePair(module spec) 


module 


DefModuleDecl(interface concepts); 


interface 


lnterfaceDecl(formal_name inherits imports export); 


where 


WhereEmpty() 


1 


WhereExp{expression_list) 


i 

optional list concepts; 


concepts 


ConceptNil() 


1 


ConceptPair( concept concepts) 


concept 


ConceptType(lormal_name type_spec where) 


1 


ConceptValue(formal_name formal_arguments where 




<ormal_arguments where) 


i 

formal_name 


FormName(identifier formal_parameters) ; 


expression list 


SingleExp( expression) 


1 


MultiExp(expression_list expression) 


9 

expression 


UndefExpO 


1 


Equal(expression expression) 


1 


Add(expression expression) 


1 


Subtract(expression expression) 


» 

identifier : 


Identifier(IDENTIFIER); 


IDENTIFIER 


ldentLex< [a-zA-Z][a-zA-Z_0-9]‘ >; 



Figure 6 

Partial Listing of Abstract Syntax for Spec 



The abstract syntax of a language must have one phylum designated as the root 
phylum. The objects that can be edited within the generated editor are terms of this root 
phylum. [Ref. 10: p. 48] 
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3. Completing Term 

Each phylum has a default value called the completing term. The editor uses 
these default values at each unexpanded occurrence of a phylum in the derivation tree of 
the object being edited. [Ref. 10: p. 48] 

The completing term of a phylum is constructed by the first operator declared for 
that phylum, such as the operator UndefExp of phylum expression and the operator 
WhereEmpty of phylum where in Figure 6. This completing operator is applied to the 
completing terms of its argument phyla. (List phyla or optional phyla are exceptions to 
this rule, as described in Sections IV. B. 5 and IV. B. 6 below.) [Ref. 10: pp.48] For 
example, the completing term for phylum module defined in Figure 6 is the term 
De(ModuleDecl(lntertaceDecl(FormName(...),lnheritNil,lmportNil,ExportNil) l ConceptNil) 
i.e., the completing operator for module applied to the completing terms of phyla 
interface and concepts. Notice that the completing term for phylum interface had to be 
constructed in the same manner before the completing operator of phylum module could 
be applied to it. 

4. Placeholder Term 

Each phylum has an associated placeholder term which is also a default represen- 
tation for its respective phylum. The placeholder is used to represent an "unexpanded" 
node in the derivation tree of the object being edited, i.e., it represents a "to be 
determined" value for the respective phylum. [Ref. 10: p. 69] 

Phyla declarations may have property declarations that determines the behavior 
of the placeholder term. The property declarations can declare a phyla as an optional 
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phylum, a list phylum, or an optional list phylum. Any phylum that does not have one of 
these declared properties is referred to as an ordinary phylum. For ordinary phyla and 
non-optional list phyla, the placeholder term and the completing term for the respective 
phylum are identical. However, for phyla declared as optional or an optional list, the 
concepts are different as explained in Sections IV.B.5 and IV.B.6. [Ref. 10: p. 77] 

The placeholder term often displays the default representation of its phylum as a 
string of characters consisting of the phylum name enclosed in angle brackets, e.g., 
<COncept> or <identifier>. Such a display representation is not mandatory, however. 
For example, in the SPECDEF editor, the placeholder term (and completing term) for 
each of the phyla field, type_spec, and expression is the symbol ?, which is the Spec 
notation for an undetermined value that must be defined later. 

In any case, the placeholder term is used at an unexpanded node in the derivation 
tree. Even though the derivation tree contains placeholders, it is still a complete 
derivation tree from the system’s point of view. [Ref. 10: p. 49] 

5. Lists and Optional Lists 

Certain phyla are designated as lists. A list represents a sequence of items, such 
as an argument list in a subprogram. Phyla declared as lists must have exactly two 
operators, one being a nullary operator and the other a binary operator that is right 
recursive. In the example shown in Figure 7, phylum StmtList is declared as a list 
phylum, with the nullary operator StmtListNil and the binary, right recursive operator 
StmtListPair. [Ref. 10: p. 49] 
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list stmtList; 
stmtList : 


StmtListNil() 


1 


StmtListPair(stmt stmtList) 



Figure 7 

Declaring a list phylum 



List phyla can be declared as optional lists. Declaring a list as optional causes it 
to behave as a list of zero or more elements, whereas a non-optional list behaves as a list 
with at least one element. [Ref. 10: p. 82] 

The completing term for list phyla and optional list phyla is defined differently 
than for ordinary phyla, for a non-optional list, the completing term is constructed by 
applying the binary operator to the completing term of the left-argument phylum and to 
the list’s nullary operator. This has the effect of concatenating the completing term of the 
left-argument phylum with the nullary operator of the list phylum, resulting in a singleton 
list. For optional list phyla, the completing term is simply the constant term formed from 
the nullary operator of the phylum. [Ref. 10: pp. 77-82] 

The placeholder term for list phyla (whether optional or non-optional) is formed 
the same as the completing term had the phylum been declared as a non-optional list. As 
an example, the completing term for phylum spec in Figure 6 is the term 

ModulePair(DefModuleDecl(lnterfaceDecl(...), ConceptNil), ModuleNil) 
i.e., ModulePair applied to the completing term of phylum module and to the term 
ModuleNil. [Ref. 10: pp. 79-82] 
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Editors generated by the Synthesizer Generator provide special built-in actions for 
manipulating list phyla. The system command forward-with-optionals < A M or 
RETURN> or forward-preorder < A N> is used to move the selection point forward in a 
derivation tree to the next node in a preorder traversal (see Appendix C for information 
on executing system commands). When moving the selection through a list, the editor 
automatically inserts a placeholder term before and after each list element. If the place- 
holder term is not edited (i.e., transformed through template insertion or text entry, both 
described later), when the selection is moved to an element that is not contained within 
the placeholder term, the placeholder is deleted from the derivation tree. Because this 
insertion and deletion process is automatic, these placeholder terms are referred to as 
transient placeholders. [Ref. 10: pp. 69-72] 

The qualifier optional introduces a distinction between a phylum’s completing 
term and its placeholder term. As stated previously, for ordinary phyla and non-optional 
list phyla, the completing term and placeholder term of the respective phylum are 
identical. When the current selection is an optional list phylum, the completing term is 
automatically replaced by the phylum’s placeholder term. If the placeholder term is not 
edited through template transformation or text entry (both described later), and the 
selection is moved outside the scope of the placeholder, the placeholder is automatically 
replaced by the completing term. [Ref. 10: pp. 76-82] 
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6. Optional (Non-List) Phyla 

Elements of the language that are optional can be declared as optional phyla. 
Optional list were discussed in the previous section. Non-list phyla can also be declared 
as optional. [Ref. 10: pp. 77-82] 

An optional (non-list) phylum can have any number of operators, but one must be 
a nullary operator. The completing term of the optional phylum is formed from the first 
listed nullary operator of the phylum in the editor specification. The placeholder term is 
formed by "completing" the first operator of the phylum that is not the completing-term 
operator. Since the completing term is formed by a nullary operator, it will contribute 
nothing to the display representation. Therefore, the order of the operator declarations 
should be arranged such that the placeholder term displays the appropriate prompt, e.g., 
the phylum name enclosed in angle brackets or some other appropriate display string. 
[Ref. 10: pp. 79-80] 

7. Lexical Phyla 

A lexical phylum is used to declare special strings of characters called lexemes 
that represent the smallest lexical units of the language, such as keywords, punctuation 
and other special characters, or literal constants such as identifiers, integers, etc. The 
three grammars that are used in an editor specification are interrelated, and lexemes play 
an important role in these relationships. In the relationship between the abstract and 
concrete grammars, lexemes are used to differentiate between similar constructs during 
semantic analysis. It should be noted that in the concrete grammar, certain lexemes can 
have more than one version or style. In the unparsing scheme, lexemes are used to 
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display keywords, punctuation, other special characters such as operator symbols, or 
constants. [Ref. 11: p. 15] 

Lexemes are defined by one or more regular expressions that are recognized by 
the lexical analyzer generator Lex [Ref. 17]. The form of a lexeme declaration is 
phylum- name : lexeme-name < regular-expression >; 
which declares that all strings generated by the given regular-expression are in the 
named phylum. There must be at least one blank separating the regular expression from 
the closing angle bracket. The regular expression itself must contain no embedded blank 
characters except those explicitly escaped by a preceding backslash. The lexeme-name is 
used in the definition of the concrete input grammar to represent an instance of the actual 
lexeme, such as a keyword or special symbol. [Ref. 11: pp. 15-17] 

The regular expressions in a lexeme declaration are exactly the regular 
expressions accepted by Lex, with only a few exceptions as follows [Ref. 1 1: p. 16]: 

• The blank character within square brackets must be escaped. 

• Definitions, as described in Section 6 of the Lex manual [Ref. 17], are not 
supported. 

In Figure 8, "C" stands for any printable character, "N" stands for any decimal 
integer, and stands for any regular expression. Each listing is a regular expression. 
The symbols "\[]- A .$?* + |()/{}%<> each have special meaning in regular 
expressions (see [Ref. 17] for full details). If they are used as literal text characters, they 
must appear within quotation marks or be escaped with a preceding backslash. Inside 
square brackets, however, only the characters \ - A and blank have special meaning. All 
other characters denote themselves. [Ref. 1 1: pp. 16-17] 
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Expression 


Meaning 


c 


the character C 


'C1C2C1 


the string C1C2C3 


\c 


the character C 


l C1C2C3} 


the character Cj , C2, or Cj 


[C,-C 3 ] 


any of the characters from Cj through Cj 


[*C]C 2 C 3 ] 


any character but Cj t C2 , and C3 




any character but newline 


A £ 


an £ at the beginning of a line 


£$ 


an £ at the end of a line 


£? 


an optional £ 


£* 


0 or more instances of £ 


£+ 


1 or more instances of £ 


EjE 2 


an Ej followed by an £2 


Ej\E 2 


an E] or an £2 


(E) 


an £ 


Ej/E 2 


an Ei but only if followed by an £2 


E{ NjM) 


Nj through N2 occurrences of £ 



Figure 8 

Construction of Regular Expressions 



Lexeme declarations are not totally independent, since their order can influence 
the recognition process during lexical analysis. When more than one regular expression 
can be matched, the longest match is made. If several rules match the same number of 
characters, the declaration defined earlier in the specification is used. Because of this, all 
keywords should be defined prior to a definition for a class of identifiers. [Ref. 11: pp. 
16-17] 

Whitespace characters (spaces, tabs, newlines) are ignored during parsing, but are 

important for the concrete input syntax. The lexeme declaration 

WHITESPACE: <[\\n\t]>; 

defines such characters for the system. [Ref. 1 1: p. 17] 
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C. PRACTICAL APPROACH TO DESIGNING AN EDITOR 



There are many aspects of an editor specification. A novice editor-designer will 
probably be confused on where to begin. The following discussion is the recommended 
approach by the authors of the Synthesizer Generator together with insights gained 
through practical hands-on experience. 

Start by choosing a simple subset of the full language. This allows the editor- 
designer to become familiar with the formats of the various sections of the editor 
specification without getting lost in the details required for the full language. Once the 
editor is implemented for this subset, and works as expected, the subset can be expanded. 
The remaining steps are listed in Table 1 below and explained in more detail in the rest of 
this section. [Ref. 10: pp. 162-169] 

Table 1: STEPS TO DESIGNING AN EDITOR SPECIFICATION 

1 . Define the abstract syntax. 

2. Define the display representation. 

3. Define template transformations. 

4. Generate and debug editor. 

5. Define concrete input syntax. 

6. Refine the display representation. 



It is recommended to design the editor specification in a modular fashion. This 
enhances the understandability of the editor specification. It also supports the reusability 
of the different "modules" in related editors, such as upward-compatible editors for 
language extensions or different editors for the same language that provide different 



39 



display formats. Reps and Teitelbaum recommend [Ref. 10: pp. 172-178] the following 
six modules for organizing an editor specification: 

• Abstract-syntax declarations and template transformations on these constructs. 

• Lexica] declarations. 

• Concrete-input syntax declarations together with precedence and associativity 
rules. 

• Attribute-domain declarations and operations on the attribute domain. (Note: the 
current version of SPECDEF does not have any attribute-domain declarations, 
such as environment attributes. However, future versions may need a file with 
these kinds of attributes.) 

• Attribute declarations and equations. 

• Unparsing declarations. 

It should be noted that the above order of modules does not correspond to the order of 
steps for designing an editor specification. This is the recommended order that the 
respective SSL files should be input to the Synthesizer Generator to create an editor. 

1. Define the Abstract Syntax 

The first step is to define the abstract syntax of the language subset A Backus- 
Naur Form or context-free grammar is a convenient starting point. Minimize 
unnecessary syntactic distinctions. For example, in the production 
exp: Const(INT); 

the numerals 007 and 7 will both be translated to the INT value 7, and displayed as the 
numeral 7. If the distinction between 007 and 7 must to be preserved, however, the pre- 
defined phylum INT should be replaced by the phylum, say, INTEGER with the lexeme 
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declaration 



INTEGER: <[0-9]+>; 

which defines numerals as strings. Leading zeros are thus preserved. [Ref. 10: p. 163] 

Omit all terminal symbols that are just "syntactic sugar", such as punctuation 
marks and keywords. Operator names will suffice to distinguish between alternative 
terms of the left-hand-side phylum. Only those terminals that carry semantic information 
should be retained in the abstract syntax, such as identifiers, numerals, and other literal 
constants. [Ref. 10: pp. 163] 

Attribution schemes can influence the design of a language’s abstract syntax. 
Phrases that are lexically identical are often used for distinct purposes. The static- 
semantic analysis then depends on the context in which the phrase is used. If all usages 
of the phrase have a common syntax, then the context must be passed down as an 
inherited attribute to select the appropriate analysis. However, if each use of the phrase 
occurs in a different phylum, the context is implicit in the phylum’s operators, and the 
correct attribute equations for the static-semantic analysis are automatically selected. It 
is an unavoidable fact that the abstract syntax may have to be changed when attribution 
rules are addressed. [Ref. 10: p. 164] 

2. Define a Display Representation 

The second step in specifying an editor is to define an initial set of unparsing 
declarations to allow the editor to display the terms of the abstract syntax. Do not be 
concerned with fancy pretty-printing at this point. Define only enough "syntactic sugar" 
to debug the abstract syntax. Specifically, do not consider alternative unparsing schemes 
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(an alternate display representation of the given production, often used for an 
"abbreviated" display), optional line breaks, context-dependent display formats, and 
special fonts now. However, line breaks and simple indentation rules are advisable at 
this stage. [Ref. 10: p. 164] 

The unparsing declarations define which productions of an object are editable as 
text as well as the display format of a term. There is an unparsing production corre- 
sponding to each production of the abstract syntax. Each unparsing production consists 
of a sequence of strings, names of attribute occurrences, names of right-hand-side 
phylum occurrences, and selection symbols. The unparsing rules take one of two forms: 

phylum : operator [left-side : right-side]', 
phylum : operator [leftside ::= right-side]', 

The unparsing scheme between the square brackets represents a concrete display format 
for the corresponding abstract syntax production. The symbol ::= indicates the 
production’s text is editable, whereas the symbol : indicates the production is (usually) 
treated as an indivisible structural unit. Not all operators of a given production have to 
use the same symbol. The left-side is a selection symbol (explained below) representing 
the left-hand-side of the corresponding abstract syntax production. The right-side is a 
sequence of strings, attribute- names and selection symbols representing the right-hand- 
side of the corresponding abstract syntax production, and defines the display format for 
that production. [Ref. 10: p. 59] 

Indentation and line breaks are indicated by the following control characters: 

%t - move the left margin one indentation unit to the right 
%b - move the left margin one indentation unit to the left 
%n - break the line and move to the left margin of the next line 
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These control characters can be included in strings (i.e., inside double quotes) of an 
unparsing rule. [Ref. 10: pp. 59-60] 

Each nonterminal (i.e., phylum name) in an abstract syntax production is replaced 
by the selection symbol @ or A in the corresponding unparsing rule. These selection 
symbols defme the selectability property for the corresponding node in the tree. The 
selection symbol @ specifies that the phylum occurrence is a resting place; the selection 
symbol A denotes a non-resting place. A resting place is a point where the corresponding 
phylum occurrence can be expanded through template insertion or text entry. Each node 
in the syntax-tree is an instance of two phylum occurrences in the grammar: as a left- 
hand-side occurrence in one production, and as part of a right-hand-side occurrence in 
another. If either of its two corresponding occurrences is specified with an @, that node 
is a resting place. [Ref. 10: p. 61] 

Care must be taken when defining unparsing schemes for list phyla. The two 
occurrences of the list phylum (i.e., the left-hand-side and the second argument on the 
right-hand-side) should be defined with @ and the element-phylum (the first argument 
on the right-hand-side) should be defined with A . This prevents an extra resting place at 
the element-phylum position. Conditional unparsing of list separators are declared inside 
square brackets. These list separators are suppressed from the display of production 
instances occurring at the end of a list. For example, in Figure 9, the ["%n%n"] in the 
unparsing declaration for ModulePair cause each element of the list to be separated by a 
two line-feeds. [Ref. 10: p. 61] 
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The unparsing declarations should initially contain the maximal number of resting 
places to allow full exploration and debugging of the abstract syntax. Plan on elimi- 
nating undesirable resting places later by changing some of the phyla occurrences from 
@to A . [Ref. 10: p. 164] 

Primitive (lexical) phyla occurrences are an exception to this rule-they should 
not be resting places. This has the effect of forcing the resting place one node higher in 
the tree. To see why this is useful, imagine the following situation based on the abstract 
syntax and unparsing rules for a desk calculator depicted in Figure 10. Suppose the 
selection is positioned at an occurrence of phylum I NT in one of the desk calculator’s 
expressions. The pre-defined primitive phylum I NT has a placeholder term of 0, which 
would replace the selection if the command delete-selection < A K> were executed and 
INT was a resting place. But if INT is not a resting place, the selection is forced one 
level higher to Const(INT). Now if the command delete-selection is executed, the 
placeholder term for exp, namely Null, replaces the selection. The display representation 
for Null is the string <exp>. [Ref. 10: pp. 163-165] 

Since occurrences of primitive phyla are not resting places, in operators of arity 
two or more, the primitive phyla occurrences will not be individually selectable. 
Therefore, an extra syntactic level is necessary to allow the individual selection of 
components. Failure to add this extra level is a common mistake made when designing 
an editor specification. [Ref. 10: p. 165] 
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start 


Spec 


[@:@] 


spec 


ModuleNil 
Module Pair 


[@ :>] 

[@ A ["%n%n"] @] 


module 


DefModuleDecI 


[@ :> "DEFINITION " @ @ "%n" 
"END"] 


interface 


Interface Decl 


@ "%t%n" @ "%n" @ "%n" @ "%b%n"] 


where 


WhereEmpty 

WhereExp 


[@ :> 1 

[@ :> "WHERE " @] 


concepts 


ConceptNil 

ConceptPair 


[@ "= ] 

[@ A ["%n”] @] 


concept 


ConceptType 


[@ ::= "%t%n""CONCEPT " @ " : " @ "%t%n" 
@ "%b%b%n"] 


1 


ConceptValue 


[@ ::= "%t%n"”CONCEPT " @ @ "%t%n" 
@ "%n" 

"VALUE " @ *%n" @ "%b%b%n"] 


formal_name : 

> 


FormName 


[@ @ " @] 


expression Jist: SingleExp 


[@ ::= @] 




MultiExp 


i 

ii 

© 


expression 


UndefExp 


[@ ::= "?"] 




Equal 


[@ @ " - " @] 




Add 


@ " @] 




Subtract 


[@ ::= @ " - " @] 


identifier 

• 


Identifier 


[@ :> A ] 



Figure 9 

Partial Listing of Spec Unparsing Declarations 
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root calc: 
list calc; 
calc : 


CalcNilO 






1 


CalcPair(exp calc) 




1 

exp 


Null() 






i 


Sum, Diff, Prod, Quot(exp exp) 


i 

» 


Const (INT) 






calc 


CalcPair 


[@ 


> @ "%n VALUE - ??T^/on%n"]@); 


exp 


Null 


[@ 


> *<exp>T 


1 


Sum 


[@ 


:« ■(■ @ * + " @ ")1 


1 


Diff 


[@ 


> *(* @ * - - @ *n 


1 


Prod 


[@ 


> *(" @ " * " @ *)"] 


1 


Quot 


[@ 


:= "(" @ ' / " @ ")*] 


1 

9 


Const 


[@ 


:= A ] 



Figure 10 

Desk Calculator abstract syntax and unparsing rules 



3. Define Template Transformations 

The third step in designing an editor specification is to provide a set of transfor- 
mation declarations, or template transformations to restructure an object when the current 
selection is a placeholder. The purpose of a template transformation is to replace the 
placeholder term with the template of one of the other productions of the respective 
phylum. The form of a transformation declaration is 

transform X 0 on transformation-name <Xo> ’ operator ( <X]>,...,<X „> ); 
which corresponds to the abstract syntax production 
X 0 : operator (Xi..JC„) 

Each <X,> denotes the placeholder term of the phylum X,-. [Ref. 10: p. 166] 
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As with other kinds of SSL declarations, the phylum name X 0 can be factored to 
the left when there are multiple transformations on the same phylum [Ref. 1 1: p. 86]: 
transform X 0 

on transformation-name ; <X 0 > : operator j (<Xj>,...,<X„>), 
on transformation-name 2 <Xo> • operator (<Yj>,...,<Y„>), 

on transformation-name k <X 0 > : operator k (<Z 1 >,...,<Z n >) 



The transformation-name is enclosed in double quotes and constitutes command 
that can be invoked to replace the placeholder term with the invoked template (see 
Appendix C for information on invoking template transformations). Figure 1 1 is a partial 
listing of the template transformations for Spec. 

List phyla and optional phyla do not normally require template transformations. 
Commands that move the selection (e.g., forward-with-optionals [ A M or RETURN] and 
forward-sibling-with-optionals [ESC- A M]) provide adequate transformations for these 
phyla. [Ref. 10: p. 166] 



transform concept 

on "type” <concept>: ConceptType(<formal_name>,<type_spec>,<where>), 

on "value" <concept>: ConceptValue(<formal_name>,<formal_arguments>, 

<where>,<formaLarguments>,<where>) 

i 

transform expressionjist 

on "single" <expression_list>: SingleExp(<expression>), 

on "multiple" <expression_list>: MuttiExp(<expression_list>,<expression>) 

» 

transform expression 

on "=" <expression>: Equal(<expression>,<expression>), 

on "+" <expression>: Add(<expression>,<expression>), 

on "-" <expression>: Subtract(<expression>,<expression>) 



Figure 1 1 

Partial Listing of Spec Template Transformations 
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4. Generate and Debug Editor 

At this stage the partial editor specification defines enough of the editor’s 
structure-editing facilities to allow the Synthesizer Generator to create an editor and for 
you to test the editor’s characteristics. Invoke sgen on the specification files. By 
default, the created editor will be placed in the file syn.out. This can be overridden with 
the -0 option which allows the user to declare what filename the editor will be called. 
[Ref. 10: p. 167] 

Recommended options to include at this point are the -w window-system-name 
window option, which specifies that the editor will be created for the specific window- 
system- name, and the -v option, which invokes Yacc [Ref. 18] with the -v flag so the 
diagnostic file y. output will be produced. This file is useful for debugging the 
specification file. [Ref. 10: p. 288] 

The y. output file produced by Yacc is a complete listing of the state machine 
model that represents the created editor. If there are any parsing conflicts in the editor 
specification, these can be located in the y. output file by loading it into the vi editor and 
doing a search for the word conflict. Specifically, the types of conflicts that can occur 
are shift/reduce and reduce/reduce conflicts, both of which are described in detail below. 

5. Define Concrete Input Syntax 

Next, define the concrete syntax for textual input. The concrete syntax consists of 
lexical declarations, parsing declarations, and correspondence rules for connecting the 
concrete syntax and the abstract syntax. Initially, provide only those rules needed to 
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permit entering lexemes and simple expressions. The rules can be elaborated later to 
permit text entry for additional language constructs. [Ref. 10: p. 167] 

The term text editing refers to the process of modifying the textual representation 
of an object through operations on the character sequence [Ref. 10: p. 108]. Structure 
editing is the process of modifying the underlying abstract syntax tree structure of an 
object [Ref. 10: p. 95]. 

Text editing is more appropriate than structure editing for entering and modifying 
expressions. It is also needed for entering identifiers. While a subterm is being edited, 
the usual rigors of the syntax directed discipline are temporarily suspended, since the 
subterm being edited can be any string whatsoever. When the editing is complete, the 
string is parsed and translated to the corresponding term of the abstract syntax. [Ref. 10: 
p. 62] 

fl. Parsing Declarations 

The parsing declarations that define the concrete input syntax are distin- 
guished from the other phylum and operator declarations of an SSL specification by 
using the symbol ::= instead of : to separate the left-hand-side phylum name from the 
right-hand-side symbols. Additionally, parsing declarations may have tokens (single 
characters enclosed in quotes) interspersed among the phylum symbols on the right-hand- 
side. 

Each parsing declaration has the form: 

phylum-name ::= operator-name (tokens phylum j tokens phylum 2 ... phylum * tokens); 
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Some of the phylum i may be lexical phyla that define keywords or other multi-character 
tokens. Knowing which string occurred in the input is usually relevant. Therefore, the 
corresponding string appears as the i-th argument of the operator in the parse tree. 
Examples of parsing declarations are shown in Figure 12. [Ref. 11: pp. 76-77] 

Attribute equations for constructing terms from text input are combined with 
the parsing declarations using the following syntax: 

phylum-name operator-name (parsing-scheme) {equations}; 

Synthesized attributes of the left-hand-side phylum and inherited attributes of the right- 
hand-side phylums are termed the production’s output attributes. An attribute equation 
defines the value of an output attribute in terms of other attributes accessible within the 
production. The attribute equation(s) are grouped inside curly braces. An output 
attribute b of phylum X is denoted by X.b. If there is more than one occurrence of 
phylum name X in an attribute equation, the various occurrences of b are denoted (from 
left to right) by X$1.6, X$2.b, etc. An attribute b of a left-hand-side phylum of a 
production can be denoted by $$A [Ref. 11: pp. 27-28] 

Examples of attribute equations are shown in Figure 13. In the attribute 
equations for SPECDEF, the attribute t is for text. As an example of how the attribute 
equations work, let’s examine the equation for phylum FormalName. The text attribute 
for FormalName is given the value formed by applying the abstract syntax operator 
FormName to the value of the text attributes of the concrete input phyla Ident and 
FormalParm. 
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Module 


(DEFINITION Interface Concepts END); 


Interface 


::= (FormalName Inherits Imports Export); 


Concepts 


:;= (Concept) 




| (Concept Concepts) 


FormalName 


::= (Ident FormalParm); 


FormalParm 


:> () 




| (’{’ Field-ist ’}’ Where) 

» 


Ident 


(IDENTIFIER); 



Figure 12 

Concrete Syntax Parsing Declarations 



The format of attribute equations for list phyla is different. Examine the 
attribute equations for phylum Concepts in Figure 13. For the first production, the text 
attribute of Concepts is given the value formed by concatenating the value of the text 
attribute of phylum Concept with the nullary term ConceptNil. For the second 
production, the new value of the text attribute of phylum Concepts, designated on the 
left-hand-side as ConceptS$1 .t, is given the value formed by concatenating the value of 
the text attribute of the phylum Concept with the previous value of the text attribute of 
phylum Concepts, designated on the right-hand-side as ConceptS$2.t. Recall that 
multiple occurrences of a phylum name X within an attribute equation are differentiated 
left to right as X$1 , X$2, etc. 
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Module 


::= (DEFINITION Interface Concepts END) 

{Module. t m Def Modu le Ded(lnterf ace. t. Concepts, t);) 


Interface 


(FormalName Inherits Imports Export) 

(Interface. t * kiterfaceDed(FormalName.t,lnherits.t 
Im ports, t, Export t);} 


Concepts 


::= (Concept) (Conoepts.t = (Conceptt :: ConceptNil);} 

| (Concept Concepts) 

(ConceptsSl.t « (Conceptt :: Concepts$2.t);} 


FormalName 


(Ident FormalParm) 

{ Formal Name.t * FonTiName(ldenttFornWParm.t);) 


Formal P arm 


::= () {SS.t * Formal ParmEmpty();) 

| (*{• Field List T Where) 

{FormalParm.t = Forma)ParmUst(FieidUsU,Where.t);} 


Ident 


(IDENTIFIER) (Ident.t = Identifier(IDENnFIER);) 




Figure 13 

Parsing Declarations with Attribute Equations 



The operator names of parse tree terms are optional, and usually are not 
needed since the parser constructs the parse tree. A unique operator name is 
automatically generated by the parser. [Ref. 1 1: p. 78] 

b. Correspondence Between Concrete Syntax and Abstract Syntax 

To translate from text to term, rules are needed that define the association 
between the abstract syntax and the concrete input syntax, along with attribute equations 
that synthesize the term as an attribute of the parse tree. These rules are associated with 
the productions of the concrete syntax, which is thus extended to become an attributed 
grammar which generates terms of the abstract syntax. [Ref. 10: p. 62] 

Attributes must be defined with an attribute declaration which has the form 
concrete-syntax-phylum { synthesized abstract-syntax-phylum attribute-name;}; 
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Examples of attribute declarations are shown in Figure 14. Note that the reserved word 
synthesized can be abbreviated as syn. [Ref. 11: pp. 24-25] 



A convenient convention for naming the concrete syntax phylum is to use the 
same name as the corresponding abstract syntax phylum and capitalize the first letter of 
each "word" within the name (e.g., FormalName). Occasionally you may have to invent 
some other name if such a capitalized name has already been used, for example, as an 
operator in the abstract syntax declarations. Attribute names are often abbreviated words 
or phrases that are descriptive of what kind of attribute they are naming (e.g., t for text, 
env for environment, etc.) [Ref. 1 1: p. 9; 10: p. 63] 

Entry declarations establish the correspondence between selections in the 
abstract syntax and entry points within the concrete input syntax. Each entry declaration 
has the form: 

abstract-syntax-phylum ~ concrete-syntax-phylum.attribute-name ; 

This declaration specifies that when the current selection in the abstract-syntax tree is a 
node of phylum abstract-syntax-phylum, the input is parsed according to the parse declar- 
ations of concrete-syntax-phylum, and the value of attribute concrete-syntax- 
phylum. attribute- name is inserted into the abstract- syntax tree, replacing the currently 
selected subterm or sublist. Figure 14 is a partial listing of text attribute declarations and 
entry declarations for Spec. [Ref. 10: pp. 62-65; 1 1: pp. 74-76] 
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Module 


{ syn module t; }; 


Interface 


{ syn interface t; }; 


Where 


{ syn where t; }; 


Concepts 


{ syn concepts t; }; 


Concept 


{ syn concept t; }; 


FormalName 


{ syn formal_name t; }; 


ExpList 


{ syn expressionjist t; }; 


Exp 


{ syn expression t; }; 


Ident 


{ syn identifier t; }; 


module 


Module.t; 


interface 


Interfaced; 


where 


Where.t; 


concepts 


Concepts.t; 


concept 


Concept.t; 


formal_name 


~ FormalName.t; 


expressionjist 


ExpList.t; 


expression 


Exp.t; 


identifier 


~ Ident.t; 



Figure 14 

Association Between Abstract Syntax and Input Syntax 



c. Concrete Lexical Declarations 

Lexical phyla should be declared for each keyword and other multi-character 
token of the language. A declaration for the special token WHITESPACE should be 
included at this point if it has not been previously declared. Examples of lexical 
definitions are shown in Figure 15. [Ref. 10: p. 167] 
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WHITESPACE: 


WhiteSpace< [\ M\n]* >; 


AND: 


AndLex< "&" >; 


OR: 


OrLex< "1" >; 


NOT: 


NotLex< --- >; 


CONCEPTS: 


ConceptLex< "CONCEPT >; 


DEFINITION: 


DefnLex< "DEFINITION" >; 


END: 


EndLex< "END" >; 


SEMI: 


SemiLex< ";" >; 


PLUS: 


PlusLex< "+" >; 


MINUS: 


MinusLex< "-" >; 


INTEGER LIT: 


lntegerLex< [0-9]+ >; 


IDENTIFIER: 


ldentLex< [a-zA-Z][a-zA-Z_0-9]* >; 



Figure 15 

Lexical Definitions 



d. Parsing and Ambiguities 

The Synthesizer Generator uses the parser generator Yacc [Ref. 18] to create 
the editor’s parser. As the parser scans the input stream, it pushes and pops tokens 
onto/from a stack according to the parsing declarations. A shift pushes the next token a 
onto the stack; a reduce pops tokens off the stack when all tokens necessary to complete 
a parsing rule have been seen. The resulting token (an occurrence of the left-hand-side of 
a parsing declaration) is then pushed onto the stack before the next token a is parsed. 

Yacc will detect and report any ambiguities in the input grammar. Ambigu- 
ities are of two types: a shift/reduce conflict or a reduce/reduce conflict. A shift/reduce 
conflict arises when the parser cannot determine, based on the stack contents and the next 
token a, whether to apply a reduction rule or to shift a onto the stack, thereby deferring 
the reduction. A reduce/reduce conflict arises when the parser can apply more than one 



55 



reduction rule to the current contents of the stack. By default, Yacc resolves these 
conflicts as follows: 

• For a shift/reduce conflict, perform the shift. 

• For a reduce/reduce conflict, reduce by the production declared earliest in the 
specification. 

These resolution rules will often not do what you intended. Therefore, some additional 

mechanism is required to resolve ambiguities. [Ref. 1 1: p. 79] 

Precedence declarations provide this additional mechanism for resolving 

ambiguities in the input grammar. They must be listed prior to the parsing declarations. 

These precedence declarations associate precedence levels with characters and lexemes. 

There are three forms of precedence declarations: 

left token-or-phylumi,...,token-or-phylumk, 

rig ht token-or-phylum j , . ..,token-or-phylumk ; 

nonassoc token-or-phylum 1> ...,token-or-phylemk, 

Each token-or-phylum can be a single CHAR constant, such as or the 

name of a lexical phylum, such as IDENTIFIER. The same precedence level and 

associativity is assigned to all characters and lexemes denoted by token-or- 

phylum],...,token-or-phylumk. The order in which precedence declarations are listed in 

the SSL specification is extremely important— each successive declaration receives a 

higher precedence than the previous declaration(s) (i.e., precedences are declared low-to- 

high). The keywords left, right, and nonassoc define the associativity of the listed 

tokens. The effects of precedence and associativity are described below. [Ref. 1 1: p. 79] 

The final token in a concrete syntax production determines the precedence 

level and associativity of the production. Precedences and associativity can be associated 
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with complete productions as well as with tokens. To assign an explicit level of 
precedence to a production, which could be either the same as or different than the 
precedence level of the last token (if one is present at all), the parsing declaration uses the 
form: 

phylum-name ::= operator- name (list-of-tokens-and-phyla prec token-or-phylum); 
Yacc uses these precedence rules to disambiguate the productions of the input grammar 
as follows: 

• When there is a reduce/reduce conflict, or there is a shift/reduce conflict and 
either the input symbol (i.e., character or lexeme name) or the grammar rule has 
no precedence and associativity, the disambiguation rules stated above are 
applied and the conflicts reported. 

• If there is a shift/reduce conflict, and both grammar rule and input character have 
precedence and associativity, the conflict is resolved in favor of the action (shift 
or reduce) associated with the higher precedence. If precedences are the same, 
associativity is used: left associative implies reduce; right associative implies 
shift; nonassociating implies error. 

Using the -v option of sgen is extremely helpful in debugging such conflicts. The 
y. output file generated by Yacc will indicate all shift/reduce and reduce/reduce conflicts 
and which tokens caused them. After running sgen, edit this file and perform a search 
for the word "conflict". [Ref. 11: p. 80] 

Figure 16 is a partial listing of the lexical phyla, precedence declarations, and 
concrete syntax parsing declarations for SPECDEF. 
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r lexical phyla 7 

WHITESPACE: WhlteSpace< [\ MVn]* 



CONCEPT: 

DEFINITION: 

END: 

VALUE: 

WHERE: 

SEMI: 

COMMA: 

PLUS: 

MINUS; 


ConceptLex< "CONCEPT* >; 
DefnLex< "DEFINITION* >; 
EndLex< "END" >; 
ValueLex< "VALUE" >; 
WhereLex< "WHERE" >; 
SemiLex< ";" >; 

CommaLex< "," >; 

PlusLex< "+" >; 

MinusLex< "-" >; 



r precedence and associativity rules V 
left SEMI IDENTIFIER; 
left 7 COMMA; 

left *=’; 

left V PLUS MINUS; 

r concrete input syntax 7 

Module : = (DEFINITION Interface Concepts END) 





{Module. t = DefModuleDed(lnterface.t,Concepts.t);} 


Interface 


::= (Formal Name Inherits Imports Export) 

{Interface.t = lnterfaceDecl(FormalName.t l lnherits.t,lmports.t l Export.t);} 


Where 


::= (prec SEMI) {$$.t = WhereEmpty();) 

| (WHERE ExpList) (Where. t = WhereExp(ExpUstt);} 


Concepts 


::= (Concept) {Concepts. t = (Con cep tt :: ConceptNil);) 

| (Concepts Concept) {Concepts$1.t = (Concept. t :: Concepts$2.t);) 


Concept 


::= (CONCEPT FormalName TypeSpec Where) 

{Concepts = ConceptType(FonmalName.LTypeSpec.t, Where. t);) 

| (CONCEPT FormalName FormalArg Where VALUE FormalArg Where) 

{Concept t = ConceptValue(ForrnaJName.t,FormalArg$1.t,Where$1.t, 
Formal Arg$2.t,Where$2.t);} 


FonmaJName 


::= (Ident FormalParm) {FormalName. t * FormNameOdent.LFormalPanm.t);} 


Exp List 


::= (Exp prec COMMA) {ExpUstt = Sing leExp( Exp t);} 

| (ExpList 7 Exp prec COMMA) {ExpList$1.t = MultiExp(ExpList$2.t,Exp.t);) 


Exp 


::= (?) {Exp.t « UndefExpO;} 

| (Exp v Exp prec ’=’) {ExpSl.t * EquaKExp^.tExpSa.t);} 

| (Exp V Exp prec PLUS) {ExpSl.t « Add(Exp$2.t l Expi3.t);} 

| (Exp Exp prec MINUS) {ExpSl.t = Subtract(ExpS2.t 1 Exp$3.t);} 


Idem 


::= (IDENTIFIER) {Ident.t = ldentifier(IDENTlFIER);) 




Figure 16 

Lexical Phyla, Precedence and Associativity Rules, and 
Concrete Input Syntax Parsing Declarations for SPECDEF 
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6. Refine the Display Representation 

The final step to complete the initial version of the editor specification is to refine 
the display representation. In Section IV.C.2 we suggested that the unparsing declar- 
ations be written with the maximal number of resting places. Any undesirable resting 
places should now have their selection symbol changed from @ to A . It is very important 
that the selection symbols in lists are defined according to the pattern shown in Figure 17 
because selections in lists are handled specially. [Ref. 10: p. 171] 



abstract syntax rule 




unparsins rule 


list listType; 
listType : 


ListTypeNullQ 


[@ ::=] 


1 


ListTypePairjlistElement listType) 


[@ ::= A @] 


listElement 


ListElementNull() 


[ A ::= "<listElement>T 



Figure 17 

Unparsing pattern for list phyla 



For example, the unparsing declarations shown in Figure 9 should be changed to 
have some of the selection symbols on the left-hand-side of the unparsing rules changed 
from @ to A as shown in Figure 18. 

Finally, the editing-mode symbols in the unparsing declarations (i.e., the ::= and : 
symbols) need to be checked that they specify the desired text-editing properties for the 
various operators. Specifically, if the operator allows text entry, the ::= symbol should be 
used, but if text entry or text re-editing is not allowed, the : symbol should be used. Note 
that the symbol ::= also allows textual re-editing of elements. Therefore, if the designer 
wanted to allow the entry of individual lexemes but not full expressions, the unparsing 
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rules for the phylum expression should be changed from what was shown in Figure 18 
to those shown in Figure 19. [Ref. 10: p. 172] 



start 


Spec 


[@ 


:@] 


spec 


ModuleNil 


[@ 


:>] 




ModulePair 




A [*%n%n"] @] 


module 


DefModuleDecI 


l@ 


■DEFINITION * @ @ "%n" 
’END"] 


interface 


InterfaceDecI 


[@ 


@ "%t%n" @ *%n" @ "%n" @ "%b%n"] 


where 


WhereEmpty 


[ A : 


: = ] 




WhereExp 


r :: 


;= "WHERE " <g>] 


concepts 


ConceptNil 


[@ 


::=] 


1 


ConceptPair 


[@ 


A ["%n"] @] 


concept 


ConceptType 


r : 


:= "%t%n”"CONCEPT “ @ " : ■ @ “%t%n“ 
@ *%b%b%n"] 


1 


ConceptValue 


[ A : 


> "%t%n""CONC E PT “ @ @ “%t%n" 
@ "%n* 

"VALUE ■ @ "%n“ @ "%b%b%n“] 


formal_name : 

1 


FormName 


[ A : 


II 


expressionjist: SingleExp 


[ A : 


:= @] 


1 


MuttiExp 


[ A :: 


:= @ " @] 


i 

expression 


UndefExp 


[ A : 


= “?"] 


1 


Equal 


[ A : 


« @ * * " @] 


1 


Add 


[ A : 


= @ ■ + ■ @] 


1 


Subtract 


[ A : 


= @ " - " @] 


identifier 


Identifier 


[ A :: 


- A ] 



Figure 18 

Refined Unparsing Declarations for Spec 
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expression 


UndefExp 


[ A :> "?"] 


i 


Equal 


[ A : <§> " = ■ @] 


i 


Add 


[ A : @ " + " @] 


i 

i 


Subtract 


[ A : <a> " - " @] 



Figure 19 

Unparsing rules that forbid re-editing 



7. Advanced Unparsing Features 

We have already discussed the use of the control strings %t, %b and %n in 
unparsing declarations to signal tab, backtab, and new line, respectively. It should be 
noted that changing the left-margin (i.e., with %t or %b) has no immediate visible effect. 
The change is only evident after the start of a new line. [Ref. 1 1 : p. 64] 

To prevent the undesirable effect of having long lines of display text broken in 
mid-word, optional line breaks, indicated by %0, provide the means to specify places 
where a term’s display string may be divided into separate lines. The designer can 
impose a hierarchical structure on the display string by the matched grouping symbols 
%{ and %}. The editor will attempt to split long lines containing optional line breaks in 
such a way that the minimum number of unparsing groupings will be split and the 
amount of text on the line is maximized. A grouping only has effect if it contains an 
optional line break. If indentation is desired only for the text that follows an optional line 
break that is taken, the formatting command string %t%0%b may be used. A complete 
listing of unparsing display commands is shown in Figure 20. [Ref. 1 1: pp. 63-66] 
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Formatting 

Command 


Meaning 


%t 


move the left-margin one indentation unit to the right 


%b 


move the left-margin one indentation unit to the left 


%n 


break the line and return to the current left-margin 


%l 


return to current left-margin of the same line and overprint 


%1 


move to column one of the same line and overprint 


%T 


move right to the next tab stop 


%M(c) 


move right to column c, where c is a positive integer 


%0 


optionally, break the line and return to the current left-margin 


%c 


same as %0, but either all or no %c in a group are taken 


%{ 


beginning of an unparsing group 


%} 


end of an unparsing group 


%t 


same as %t%{ 


%1 


same as %}%b 


%S(sty le-name: 


enter the named style 


%S) " 


revert to the previous style 


%% 


display a % 



Figure 20 

Formatting Commands 



To see how some of these commands can be used, let’s look at an example of an 
unparsing declaration that includes groupings and optional line breaks. The following 
declaration uses the formatting commands for beginning and end of an unparsing group, 
beginning and end of an unparsing group with tabs and backtabs, and optional line 
breaks: 

expression : QuantifierExp [ A ::= “%{" @ "(" @ *%o" @ “%}%(%o @ ’)%]"] 

The resulting expression could be displayed in several formats that would be dependent 
on the width of the current window. Figure 21 shows these different formats with one or 
more of the optional line breaks taken. 
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ALL(item : typel SUCH THAT foo(a) < 27 :: item - ‘item + 1) 
ALL(item : typel 

SUCH THAT f 00 (a) < 27 :: item = ‘item + 1) 

ALL(item : typel SUCH THAT foo(a) < 27 
:: item = ‘item + 1) 

ALL(item : typel 
SUCH THAT foo(a) < 27 
:: item * ‘item + 1) 

Figure 21 

Effect of optional line breaks on display 



D. DESIGN DECISIONS 

1. Spec Subset 

The subset of Spec I chose to implement is the Definition Module. Definition 
modules are used in the requirements analysis phase of the software development cycle 
[Ref. 1]. Implementing an editor for the definition module provides the initial support for 
utilizing Spec in this phase of software engineering. 

2. Type Checking 

Editors created by the Synthesizer Generator can have the capability to perform 
type checking provided the proper attribute equations are written to support this 
checking. However, since other research is currently being done to implement a separate 
type checker for Spec [Ref. 15], the decision was made to not implement this capability 
in the syntax directed editor. Eventually, when the editor and the type checker are fully 
implemented, both tools will be integrated into one larger tool that will perform both 
functions. 
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3. Display Representation 

In order to make the visual display "user friendly", many of the constructs in Spec 
had productions added whose purpose is to display a placeholder string. These 
productions appear in both the abstract syntax and the unparsing grammar. The format of 
these placeholder strings is the phylum name enclosed in angle brackets, e.g., <COncept> 
or <actual_parm>. 

Although not part of the original Spec grammar, these productions are declared as 
the completing term for the respective phylum. The phyla that have this additional 
production are all non-list phyla, therefore the completing term is also the placeholder 
term for the given phylum. This causes the visual display to show where a selection 
should be made at a later time if a template transformation is not selected. 

Some constructs in Spec already have a usable completing term, specifically field, 
type_spec, and expression, which all use the symbol ? to represent undefined 
occurrences of the respective phylum. 

4. Naming Conventions 

The following conventions were selected for naming of phyla, operators, and 
attributes: 

• Abstract syntax phyla are all lower case (e.g., concept), and are exactly the same 
as the original Spec grammar. 

• Operators on abstract syntax phyla have the first letter of each "word" within the 
operator name capitalized (e.g., NotGreaterEqual). 

• Lexemes are fully capitalized (e.g., IDENTIFIER). 
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• Lexical phyla operators are capitalized with the same conventions as abstract 
syntax phyla operators. Additionally, with the exception of the special lexical 
phylum WHITESPACE, each of these operators ends in the word Lex (e.g., 
NgeLex). 

• Template transformation names are all lower case (e.g., "single"), or are a symbol 
made of one or more non-alphanumeric characters (e.g., "+" or "~>="). 

• Concrete input syntax phyla have the same name as the corresponding abstract 
syntax phyla (with only a few exceptions) with the first letter of each "word” 
within the name capitalized (e.g., FormalName or IntegerLit, corresponding to 
abstract syntax phyla formal_name and integerjit, respectively). 

• Attributes are all labelled as a lower case t, since the only attributes used in this 
editor are synthesized text attributes. 

5. Implementation 

A listing of the current implementation of SPECDEF is given in Appendix B. A 
user’s manual for the current version of SPECDEF appears as Appendix C. 
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V. CONCLUSIONS 



A. APPLICABILITY OF THE SYNTAX DIRECTED EDITOR FOR SPEC 

The SPECDEF editor successfully demonstrates the feasibility of designing a CASE 
tool for the specification language Spec. The current version of the editor supports a 
subset of Spec consisting solely of definition modules and prevents the user from writing 
syntactically incorrect specifications. All Spec constructs that are applicable to a 
definition module are implemented in the editor. The SPECDEF editor provides the 
means to quickly and correctly write Spec definition modules in support of the 
requirements analysis phase of the software development cycle. 

The display representation is designed in such a way that the editor can assist the 
novice user in learning the syntax of Spec. As with other syntax directed editors for 
other languages, this could be seen as a hindrance or an annoyance to the more 
experienced Spec specification writer, since the method of building a parse tree of the 
specification being edited requires the user to traverse the entire parse tree of the Spec 
grammar itself. 

A significant foundation has been laid for designing an editor that will implement the 
entire Spec language. Approximately half of the Spec grammar rules have been 
implemented. 
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B. USEFULNESS OF THE SYNTHESIZER GENERATOR 

The Synthesizer Generator proved to be an extremely useful, albeit sometimes 
difficult, CASE tool to assist in the design and implementation of a syntax directed 
editor. The book and reference manual for the Synthesizer Generator [Ref. 10 and 1 1] 
are not always clear in their explanations of the various concepts that must be mastered to 
write a successful editor specification. 

I found it very advantageous to refer to the specification of the toy.syn editor, one of 
the sample editors that comes with the sgen system. The specification file toy.ssl can be 
found in the /usr/suns2/local/syn/editors/toy directory on the suns2 system. There are 
several other sample editors in the /editors subdirectory of /syn whose specification files 
may provide insight to some readers. 

The various options available when invoking sgen make the Synthesizer Generator 
system very versatile. Specifically, the -V option to flag Yacc to produce the diagnostic 
file y. output is extremely useful in debugging ambiguities in the input grammar. The 
ability of sgen to create an editor for different windowing systems using the -W option 
makes this system very powerful, since the same input file(s) can be used to create many 
different editors that target specific systems. 

The Synthesizer Generator creates many intermediate files during the process of 
generating an editor. Unless you have prodigious amounts of free memory available, I 
highly recommend that the -I option (lower case L) not be invoked. This option saves all 
intermediate files, which can easily use up several megabytes of memory. Under normal 
operation these files are deleted once the executable editor file is generated. 
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Learning the editor system commands to navigate around the parse tree of a specifi- 
cation being edited is rather difficult. There is quite a list of commands available; a 
complete list appears as Appendix D. However, only a portion of the commands are 
routinely used to edit a specification, as listed in Table 2. The use of these co mman ds is 
discussed in the user’s manual, which appears as Appendix C. Once these co mman ds are 
learned, writing a Spec definition module is quick and easy. 



Table 2: COMMONLY USED EDITOR COMMANDS 



Command 


Kev-binding 


backward-preorder 


< A P> 


beginning-of-Iine 


< A A> 


delete-next-character 


< A D> 


delete-other- windows 


< A X1 > 


delete-previous-character 


< DEL > 


delete-selection 


< A K> 


end-of-file 


< ESC-> > 


end-of-line 


< A E> 


enlarge-help 


< ESC- A Xz > 


erase-to-beginning-of-line 


< ESC-DEL > 


erase-to-end-of-line 


< ESC-d > 


execute-command 


< A l or TAB > 


exit 


< A C> 


forward-preorder 


< A N > 


forward-with-optionals 


< A M or RETURN > 


left 


< A B > 


next-window 


< A Xn > 


previous- window 


< A Xp> 


read-file 


< A X A R > 


redraw-display 


< A L > 


right 


< A F> 


select 


< ESC*<3> > 


start-command 


< ESC-s > 


write-named-file 


< A X A W > 
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C. DEFICIENCIES AND BUGS ENCOUNTERED 



The SPECDEF editor is strictly a syntax directed editor. There is no capability 
provided for semantic checking. As stated previously, the type checking features that 
sgen is capable of producing are not included in this editor since independent research in 
this area is currently in progress. This means that, although a specification written using 
the editor will be syntactically correct, it is possible for it to be incorrect semantically. 

One deficiency with the SPECDEF editor is the lack of support to insert comments 
into the specification being edited. Although sgen is capable of supporting this feature 
when properly specified in the editor specification, time constraints prevented the 
inclusion of this capability, which requires extensive coding to accomplish. 

D. RECOMMENDATIONS FOR FUTURE RESEARCH 

1. Implement the Complete Spec Language 

The remainder of the Spec language needs to be implemented in the editor. When 
this is accomplished, the editor will support not only the requirements analysis phase of 
the software development cycle, but also the functional specification and architectural 
design phases. 

2. Integrate the Type Checker and the Editor 

The type checker currently being implemented independently should be 
integrated with the editor once both tools are completed. This will make the editor a very 
powerful tool for software engineering with Spec. The combined tool will form the 
foundation of an integrated Spec programming environment 
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3. Integrated Spec Programming Environment 

Many different tools for Spec are under development or planned for future 
research. A pretty printer has already been designed. The type checker is currently 
under development. Future research projects include a consistency checker, an 
inheritance expander, a test oracle, and a diagram generator. There are also plans to 
design a translator from Spec specifications to compilable Ada code. 

Each of the above mentioned tools, along with the editor, are planned for 
integration into a programming environment for Spec. This environment will be capable 
of supporting the entire software development cycle. 

4. Investigate Applicability of Utilizing the GANDALF System 

The GANDALF System [Ref. 7] might be more useful than the Synthesizer 
Generator for creating a syntax directed editor. Some of the additional capabilities of 
GANDALF are the ability to generate system environments that could support multiple 
programmers on large projects, and a limited project management system. The need for 
these capabilities should be investigated, and if it is determined that such a need exists, 
future versions of the editor should be built using GANDALF instead of the Synthesizer 
Generator. 

5. Automating the Design of an SSL Specification 

After the conceptual breakthrough occurs on how to design an editor specification 
using SSL, adding more constructs to the grammar becomes a relatively mechanical 
process. The different sections of the SSL specification are closely related in terms of 
names of phyla and operators. This indicates a possibility that some aspects of designing 
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an SSL editor specification could be automated. For example, when an abstract syntax 
rule is entered, the automation process could generate the display representation rules, 
template transformation rules, etc., possibly through the use of pop-up windows that 
request specific information for naming or formatting the additional rules, or asking for 
information about attributes. 

Automating some portions of this process would enhance the usability of a tool 
such as the Synthesizer Generator. Additionally, the amount of time to produce an editor 
specification would be reduced dramatically. 
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APPENDIX A 



COMPLETE SPEC GRAMMAR 



The following is a listing of the complete grammar for the Spec specification 
language. The current version of Spec is 1.11. Optimization of the language is still 
under research, so the reader can expect further revisions to Spec in the future. 



! version stamp SHeader: spec.k,v 1.11 89/04/05 14:02:21 berzins Locked $ 

! In the grammar, comments go from a " ! " to the end of the line. 

! Terminal symbols are entirely upper case or enclosed in single quotes ('). 

! Nonterminal symbols are entirely lower case. 

! Lexical character classes start with a captial letter and are enclosed in {}. 
! In a regular expression, x+ means one or more x's. 

! In a regular expression, x* means zero or more x's. 

! In a regular expression, [xyz] means x or y or z. 

! In a regular expression, [*xyz] means any character except x or y or z. 

J In a regular expression, [a-z] means any character between a and z. 

! In a regular expression, . means any character except newline. 

! definitions of lexical classes 



%aef ine 
%def ine 
%def ine 
%def ine 
%def ine 
%def ine 
%def ine 
%def ine 



Digit 

Int 

Letter 

Alpha 

Blank 

Quote 

Backslash 

Char 



[0-9] 

{Digit } -*• 

[a-zA-Z ] 

({Letter} 1 {Digit} | 

[ \t\n] 

[ M 3 

"\\ n 

( [ An \\] I (Backslash} {Quote} I {Backslash} {Backslash}) 



! definitions of white space and comments 



: {Blank } + 

*"\n" 



l definitions of compound symbols and keywords 



AND 

OR 

NOT 

IMPLIES 

IFF 



n j n 

n = > n 
"<=> n 
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LE 




GE 

NE 


a a 

t V 

li li 
a a 


NLT 

NGT 


n n 


NLE 


n — < = n 


NGE 

EQV 


n _ n 

n zs n 


NEQV 


n _ _ _ n 


RANGE 

APPEND 

MOD 

EXP 


»i n 

*i r 

{Backslash} | MOD 

" * *« 


BIND : 

ARROW : 


► . ft 

► ft _ ^ ft 


IF : 

THEN : 

ELSE : 

IN : 

U : 


: IF 
: THEN 
:ELSE 
: IN 
: U 


ALL 

SOME : 


: ALL 
: SOME 


NUMBER : 

SUM 

PRODUCT : 

SET : 

MAXIMUM 

MINIMUM 

UNION 

INTERSECTION 

SUCH 

ELSE_IF 


: NUMBER 
: SUM 

: PRODUCT 
: SET 

: MAXIMUM 
:MINIMUM 
: UNION 

: INTERSECTION 
: SUCH (Blank } *THAT 
:ELSE {Blank }* IF 


AS 

CHOOSE 

CONCEPT 

DEFINITION 

DELAY 

DO 

END 

EXCEPTION 

EXPORT 

FI 


AS 

CHOOSE 

CONCEPT 

DEFINITION 

DELAY 

DO 

END 

EXCEPTION 

EXPORT 

FI 


FOREACH 

FROM 

FUNCTION 

GENERATE 

HIDE 

IMPORT 

INHERIT 

INITIALLY 

INSTANCE 

INVARIANT 

MACHINE 

MESSAGE 

MODEL 

OD 


FOREACH 

FROM 

FUNCTION 

GENERATE 

HIDE 

IMPORT 

INHERIT 

INITIALLY 

INSTANCE 

INVARIANT 

MACHINE 

MESSAGE 

MODEL 

OD 
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OF 

OPERATOR 

OTHERWISE 

PERIOD 

RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 

INTEGER_LITERAL 
REAL_LITERAL 
CHAR_L I TERAL 
STRING_LITERAL 

NAME 

! operator precedences 
! %left means 2-r3 + 4 is 



:OF 

:OPERATOR 
: OTHERWISE 
rPERIOD 
.•RENAME 
: REPLY 
: SEND 
.•STATE 
: TEMPORAL 
: TIME 
: TO 

: TRANSACTION 
tTRANSITION 
.•TYPE 
: VALUE 
: VIRTUAL 
: WHEN 
: WHERE 

: { Int } 

: { Int } M . " { Int } 

. n f n ni n 

: {Quote } {Char } * {Quote } 
: { Letter } {Alpha } * 



( 2 + 3 ) + 4 . 



%left 
%left 
% le f t 
% lef t 
% le f t 
%left 
% left 
%left 
%lef t 
%nonassoc 
% lef t 
% left 
%lef t 
%left 
% left 
% left 
% lef t 



' ; ' , IF, DO, EXCEPTION, NAME, SEMI; 

' , ' , COMMA; 

SUCH; 

IFF; 

IMPLIES; 

OR; 

AND; 

NOT; 

'<', '>', '=', LE, GE, NE, NLT, NGT, NLE, NGE, EQV, NEQV 
IN, RANGE; 

U, APPEND; 

'+', PLUS, MINUS; 

MUL, DIV, MOD; 

UMINUS ; 

EXP; 

'$', ' '{', ' • ' , DOT, WHERE; 

STAR; 



%% 

Jattribute declarations 



%% 

! productions of the grammar 



start 



spec 

{ ) 
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spec 



module 



: spec module 

{ ) 

I 

{ } 

9 

! A production with nothing after the "|" means the empty string 
! is a legal replacement for the left hand side. 



: function 

{ } 

| machine 

{ > 

I type 

{ } 

I definition 

{ } 

| instance ! of a generic module 

{ ) 



function 



machine 



type 



: optionally_virtual FUNCTION interface messages concepts END 

< ) 

! Virtual modules are for inheritance only, never used directly. 



: optionally_virtual MACHINE interface state messages transactions 
temporals concepts END 

i } 



: opt ionally_virtual TYPE interface model messages transactions 
temporals concepts END 
< ) 



definition 



DEFINITION interface concepts END 

< } 



instance 

: INSTANCE formal_name '=' actual_name END 

< ) 

I INSTANCE foreach actual_name END 

{ } 

! For making instances or partial instantiations of generic modules. 
! The foreach clause allows defining sets of instances. 
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interface 



: formal_name inherits imports export 
{ } 
i 

! This part describes the static aspects of a module's interface. 

I The dynamic aspects of the interface are described in the messages. 
! A module is generic iff it has parameters. 

! The parameters can be constrained by a WHERE clause. 

! A module can inherit the behavior of other modules. 

! A module can import concepts from other modules. 

! A module can export concepts for use by other modules. 

inherits 

: inherits INHERIT actual_name hide renames 

< ) 

I 

{ ) 

i 

! Ancestors are generalizations or simplified views of a module. 

! A module inherits all of the behavior of its ancestors. 

! Hiding a message or concept means it will not be inherited. 

! Inherited components can be renamed to avoid naming conflicts. 

hide 

: HIDE name_list 

{ } 

I 

{ } 

! Useful for providing limited views of an actor. 

! Different user classes may see different views of a system. 

! Messages and concepts can be hidden. 

renames 

: renames RENAME NAME AS NAME 

{ ) 

{ } 

! Renaming is useful for preventing name conflicts when inheriting 
! from multiple sources, and for adapting modules for new uses. 

! The parameters, model and state components, messages, exceptions, 

! and concepts of an actor can be renamed. 

import s 

: imports IMPORT name_list FROM actual_name 

{ ) 

I 

{ ) 



export 

: EXPORT name_list 

{ ) 

I 

{ ) 
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messages 


: messages message 
{ > 

1 

i } 

! 


message 


: MESSAGE f ormal^message operator response 

{ > 


response 


: response body 
{ } 

I response cases 
< } 


response^ 


cases 

: WHEN expression list response_body response_cases 
{ } 

1 OTHERWISE response_body 
{ } 


response 


_body 

: choose reply sends transition 
{ } 


choose 


: CHOOSE '(' field list restriction ')' 
{ } 

1 

{ } 


reply 


: REPLY actual message where 
{ } 

! GENERATE actual_message where ! used in generators 

{ } 

I 

{ } 


sends 


: sends send 
{ } 

1 

{ > 


send 


: optional foreach SEND actual message TO actual name where 
{ } 
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transition 



! for describing state changes 



: TRANSITION expression_l i st 

{ ) 

I 

{ } 

i 

f ormal_message 

: opt ional_except ion opt ional_f ormal_name f ormal_arguments 

{ ) 

act ual_mes sage 

: opt ional__except ion opt ional_actual_name f ormal_arg\iments 

{ ) 



where 

: WHERE expression_list 

{ ) 

I %prec SEMI ! must have a lower precedence than WHERE 

i 1 



opt ionally_vi rtual 

: VIRTUAL 

{ ) 

I 

{ ) 



opt ional_except ion 

: EXCEPTION 

{ ) 

I %prec SEMI 

{ ) 



operator 

: OPERATOR operator_l ist 

{ ) 

I 

i ) 



opt ionaI_fo reach 

: foreach 

{ ) 

I 

i ) 



foreach 

: FOREACH '(' field_list restriction ')' 

{ ) 

J foreach is used to describe a set of messages or instances 
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concepts 


: concepts concept 
{ } 

1 

< > 
i 


concept 


: CONCEPT formal_name type_spec where 

! constants 
{ } 

| CONCEPT formal_name f ormal_arguments where VALUE f ormal_argument s where 
! functions, defined with preconditions and postconditions 
{ ) 


model 


! data types have conceptual models for values 
: MODEL formal arguments invariant 
< ) 


state 


! machines have conceptual models for states 
: STATE formal arguments invariant initially 
{ } 


invariant 


! invariants are true for all states or instances 
: INVARIANT expression list 
{ } 


initially 


! initial conditions are true only at the beginning 
: INITIALLY express ion_l i st 
{ } 
i 


transactions 


: transactions transaction 
{ } 

1 

{ } 


transaction 


: TRANSACTION formal name '=' action list where 
{ } 

! Transactions are atomic. 

! The where clause can specify timing constraints. 


act ion_list 


: action list action %prec SEMI ! sequence 

{ } 

1 action 
{ } 
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action 



unordered set of actions 



: action action %prec STAR 

( } 

| IF alternatives FI 

{ } 

I DO alternatives OD 

{ } 

I actual_name 

{ } 

| EXCEPTION actual_name 

{ } 



J choice 

! repeated choice 

! a normal message or subtransaction 
! an exception message 



alternatives 

: alternatives OR guard action_list 

{ } 

I guard action_list 

{ } 



guard 

: WHEN expression ARROW 

{ } 

I 

{ ) 



temporals 

: temporals temporal 
{ 1 
I 

{ } 



temporal 

: TEMPORAL NAME where response 

{ } 

! Temporal events are trigged at absolute times, 

! in terms of the local clock of the actor. 

! The "where" describes the triggering conditions 
! in terms of TIME, PERIOD, and DELAY. 

opt ional_fornal_name 

: formal_name 

{ } 

I 

{ } 

forma l_name 

: NAME f ormal_parameters 

{ } 

f ormal_parameter s ! parameter values are determined at specification time 

: ' {' field_list ' }' where 

{ > 

I 

{ } 
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formal arguments ! arguments are evaluated at run-time 

: ' (' field_list ' ) ' 

{ ) 

I 

{ } 



field_list 

: f ield_list field 

{ ) 

I field 

{ } 



field 

: name_list type_spec 

{ ) 

| '$' NAME type_spec 

{ } 

I '?' 

{ ) 



type_spec 

: actual_name ! name of a data type 

{ } 

I ' ? ' 

{ ) 



name_l ist 

: r.ame_list NAME 

{ } 

I NAME 

{ ) 

opt ional_actual_name 

: actual name 



{ } 



actua l_name 

: NAME actual_parameters 

{ } 



actual_parameters ! parameter values are determined at specification time 

: ' {’ arg_l ist ' }' 

{ } 

I %prec SEMI ! must have a lower precedence than ' { ' 

{ ) 
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actual_argument s ! arguments are evaluated at run-time 

1 (' arg_list ' ) ' 



arg_list 



arg 



express ion_l is 



expression 



{ } 
{ } 



%prec SEMI ! must have a lower precedence than 



arg_list # , ' arg 
{ } 
arg 
{ } 



expression 
{ 1 
pair 
{ } 



expression__list 

{ } 

expression 

{ } 



Iprec COMMA 



, ' expression %prec COMMA 
%prec COMMA 



quantifier ' (' field_list restriction BIND expression ')' 

{ } 

actual_name actual_argument s 

{ } 

actual_name actual_name actual_argument s 

{ } 

NOT exp: 

{ } 

express 

{ } 

express 

{ } 

express 

{ } 

express: 

{ } 



< ) 

expi 
{ } 
exp 2 
{ 1 
exp: 
{ } 
expi 
{ } 
expi 
{ } 
expi 
{ } 



iion 


%prec 


NOT 


AND expression 


%prec 


AND 


OR expression 


%prec 


OR 


IMPLIES expression 


%prec 


IMPLIES 


IFF expression 


%prec 


IFF 


' <' expression 


%prec 


LE 


' >' expression 


Iprec 


LE 


'=' expression 


Iprec 


LE 


LE expression 


Iprec 


LE 


GE expression 


Iprec 


LE 


NE expression 


Iprec 


LE 


NLT expression 


Iprec 


LE 


NGT expression 


Iprec 


LE 
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expression NLE expression 

{ ) 

expression NGE expression 

{ } 

expression EQV expression 

< } 

expression NEQV expression 

{ } 

expression 



%prec LE 
%prec LE 
%prec LE 
%prec LE 
%prec UMINUS 



{ ) 

expression 
{ > 

expression 
{ } 

expression 
{ } 

expression 
{ } 

expression 
{ } 

expression 
{ } 

expression 
{ } 

expression 
{ } 

expression 
{ } 



'+' expression 
expression 
' *' expression 
' /' expression 
MOD expression 
EXP expression 
U expression 
APPEND expression 
IN expression 



%prec PLUS 
%prec MINUS 
%prec MUL 
%prec DIV 
%prec MOD 
%prec EXP 
%prec U 
%prec APPEND 
%prec IN 



expression %prec STAR 

! *x is the value of x in the previous state 



{ } 

'$' expression %prec DOT 

! $x represents a collection of items rather than just one 
I si = {x, $s2} means si = union({x}, s2) 

! si = [x, $s2] means si = append ([x], s2) 

{ } 

expression RANGE expression %prec RANGE 

! x in [a . . b] iff x in {a .. b} iff a <= x <= b 

! [a . . b] is sorted in increasing order 
{ } 

expression NAME %prec DOT 

{ ) 

expression '{' expression ' ] ' %prec DOT 

i ) 



' { ' expression ' ) ' 

{ ) 

' (' expression NAME ')' ! expression with units of measurement 

! standard time units: NANOSEC MICROSEC MILLISEC SECONDS MINUTES HOURS 

DAYS WEEKS 



{ } 

TIME 
{ ) 

DELAY 
{ ) 

PERIOD 
{ } 

1 iteral 
{ } 

literal 



{ } 



! The current local time, used in temporal events 
! The time between the triggering event and the response 
! The time between successive events of this type 

' actual_name ! literal with explicit type 
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• 7 ' 



! An undefined value to be specified later 



{ ) 

' ! ' ! An undefined and illegal value 

{ ) 

IF expression THEN expression middle__cases ELSE expression FI 

{ } 



middle cases 



middle_cases ELSE_IF expression THEN expression 

< } 

< } 



quantifier 



ALL 

{ ) 

SOME 

{ ) 

NUMBER 

{ ) 

SUM 

{ ) 

PRODUCT 

< ) 

SET 

{ ) 

MAXIMUM 

< } 

MINIMUM 

{ } 

UNION 

{ } 

INTERSECTION 

{ } 



restriction 



SUCH expression 

{ ) 



{ } 



INTEGER_LITERAL 

{ ) 

R£AL_LI TERAL 
{ } 

CHAR_LI TERAL 

{ } 

STRING_LITERAL 

{ } 

' # # NAME 
{ } 

' [ ' expressions ' ] ' 

{ } 

' { ' expressions ' } ' 

{ ) 



! enumeration type literal 
! sequence literal 
! set literal 
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I '{' expressions expression 

{ } 

| ' [ ' pair_l ist ' ] ' 

{ } 

| 9 {' NAME BIND expression ' } ' 

{ } 

9 

! relation literals are sets of tuples 

expressions 

: expression_l ist 

{ } 

I 

{ } 



pair_list 

: pair_list pair 

{ } ~ 

I pair 

{ ) 



pair 



: name_list BIND expression 

{ ) 



operator_list 

: operator_list operator_symbol 

< } 

I operator_symbol 

{ } 



operator_symbol 

: NOT 

{ } 

I AND 

{ ) 

I OR 

{ } 

i IMPLIES 

< } 

I IFF 

< } 

I 

1 } 

I 

{ ) 

I 

i ) 

I LE 

{ ) 

I GE 

{ ) 

I NE 

i ) 

I NLT 

( } 



map literal 
tuple literal 
union literal 
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I NGT 

{ } 

I NLE 

{ } 

I NGE 

{ } 

I EQV 

{ } 

I NEQV 
{ } 
l 

{ } 

I 

{ ) 

I 

{ } 

I '/' 

{ } 

I MOD 

{ ) 

I EXP 
{ ) 
l U 
{ } 

I APPEND 

{ } 

I IN 

{ } 

l RANGE 
{ } 
l # 

{ ) 

' I' 

{ } 
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APPENDIX B 



L SPECDEF SSL SPECIFICATION FILES 



The following are the SSL specification files for the current version of the SPECDEF 
editor. There are five modules broken down as follows: abstract syntax and template 
transformations, lexemes, attribute declarations, concrete input syntax, and unparsing 
schemes. 

A. ABSTRACT SYNTAX AND TEMPLATE TRANSFORMATION RULES 

The File abstract. ssl contains the abstract syntax grammar and the template transfor- 
mation rules on that grammar for the SPECDEF editor. 



/* File: 


ABSTRACT. SSL 








V 


/* 










V 


/* 


This file contains 


the abstract syntax for the 


Definition 


Module 


V 


/* 


subset of the Spec 


specification language for 


the SPECDEF 


editor . 


*/ 


/* 


It also contains the template t ransf ormat ions 


on the abstract 


V 


/* 


syntax productions. 








V 



/* abstract syntax */ 
root start; 
start : 


Spec (spec) 




/ 

optional list spec; 
spec : 

1 


ModuleNil { ) 

ModulePair (module spec) 


/* completing term */ 
/* allows addition of 
other modules */ 


module : 

interface : 


DefModuleDecl (interface concepts) 

/* Note: Spec grammar has been modified for this 

editor to go directly to the Definition 
Module declaration from Module */ 

Interf aceDecl (formal_name inherits imports export) 


optional inherits; 
inherits : 


InheritNil () 





InheritPrompt {) /* placeholder term */ 

InheritStmt ( inherits actual name hide renames) 
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optional hide; 
hide : 

1 
1 


HideNil () 

HidePromptO /* placeholder term */ 

HideList (name_list) 


optional renames; 
renames : 

1 
1 


RenameNil ( ) 

RenamePrompt ( ) /* placeholder term */ 

RenameStmt (renames identifier identifier) 


optional imports; 
imports : 

1 
l 


ImportNil ( ) 

ImportPrompt ( ) /* placeholder term */ 

ImportStmt (imports name_list actual_name) 


optional export; 
export ; 

l 

1 


ExportNil () 

ExportPrompt () /* placeholder term */ 

ExportList (name_list) 


optional where; 
where : 

1 

1 


WhereEmpty ( ) 

WherePrompt ( ) /* placeholder term */ 

WhereExp (expression_list) 



optional list concepts 



concepts : 

1 


ConceptNil () 

ConceptPair (concept concepts) 


concept : 

1 
1 


ConceptComp ( ) /* completing term */ 

ConceptType ( f ormal_name type_spec where) 

ConceptValue ( formal name formal arguments where formal arguments 


where ) 




formal_name : 


FormName (identifier f ormal_parameters) 



optional f ormal_parameters ; 
formal_parameters : Forma IP armEmpt y ( ) 

FormalParmPrompt ( ) /* placeholder term */ 

I FormalParmList ( f iela_list where) 

optional f ormal_argument s; 
f ormal_arguments : Formal ArgErrpty ( ) 



1 

1 


FormalArgPrompt ( ) /* placeholder term */ 

FormalArgList (f ield_list) 


field_list : 

1 
1 


FieldListComp ( ) /* completing term */ 

S i ng leFie Id ( field) 

Mult iField (f ield_list field) 


field : 

1 

1 


UndefFieldO /* completing term */ 

FieldNameList (name_list type_spec) 
FieldCollection ( identifier type spec) 


type spec : 

l 


UndefTypeO /* completing term */ 

NamedType (actual_name) 


name list : 

1 


Nameldent (identifier) 

NamePair (name list identifier) 
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actual_name : ActualParmList ( ident if ier actual_parameters) 

optional actual_parameters; 
actual_parameters : ActParmEmpty ( ) 

| ActParmPrompt ( ) /* placeholder term */ 

| ListOfArgs (arg_list ) 

optional actual_arguments ; 



actual_arguments : 
1 
1 


ActualArgNil ( ) 

ActualArgPrompt ( ) /* placeholder term */ 

ActualArgList (arg_list) 


t 

arg list : 

1 
1 


ArgListEmpty () /* completing term */ 

SingleArg (arg) 

Mult iArg (arg_list arg) 


i 

arg 

1 

1 


ArgCompO /* completing term */ 

ArgExp (expression) 

ArgPair (pair) 


expression_l ist : 

1 

1 


EmptyExpList () /* completing term */ 

SingleExp (expression) 

Mult iExp (expression list expression) 


i 

expression : 

1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
i 
1 
1 
1 
1 
1 
1 
1 
1 
! 
1 
1 
1 
1 
1 
1 
1 
! 
1 
1 
1 
1 
1 
1 


UndefExpO /* completing term */ 

Quant ifierExp (quantifier field list restriction expression) 
IdentExp (actual name actual arguments) 

AtExp (actual name actual name actual arguments) 

NotExp (expression) 

AndExp (expression expression) 

OrExp (expression expression) 

ImpliesExp (expression expression) 

If fExp (expression expression) 

LessThan (expression expression) 

GreaterThan (expression expression) 

Equal (expression expression) 

LessEqual (expression expression) 

GreaterEqual (expression expression) 

NotEqual (expression expression) 

NotLessThan (expression expression) 

NotGreaterThan (expression expression) 

NotLessEqual (expression expression) 

NotGreaterEqual (expression expression) 

Equivalent (expression expression) 

NotEquivalent (expression expression) 

UnaryMinus (expression) 

Add (expression expression) 

Subtract (expression expression) 

Mult iply (expression expression) 

Divide (expression expression) 

ModExp (expression expression) 

Exponent (expression expression) 

UExp (expression expression) 

AppendExp (expression expression) 

InExp (expression expression) 

Star (expression) 

CollectExp (expression) 

RangeExp (expression expression) 

DotExp (expression identifier) 

SqBracketExp (expression expression) 

ParenExp (expression) 
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MeasureExp (expression identifier) 

TimeExp ( ) 

DelayExp ( ) 

PeriodExp ( ) 

Constant (literal) 

LiteralType (literal actual_name) 

IllegalExp () 

IfThen (expression expression middle_cases expression) 



MidCaseNil () 

MiddlePrompt ( ) /* placeholder term */ 

MidCase (middle_cases expression expression) 



optional middle_cases; 
middle cases : 



quantifier 



restriction 



literal 



Quant if ierComp () 

A110 

Some ( ) 

Number () 

Sum () 

Product ( ) 

Set () 

Maximum ( ) 

Minimum ( ) 

Union ( ) 

Intersection ( ) 

Rest rictComp ( ) 
RestrictNil ( ) 
SuchThat (expression) 



/* placeholder term */ 



/* placeholder term */ 



: EmptyLiteral ( ) /* placeholder term */ 

| IntLiteral (integer_lit ) 

I RealLiteral (real_lit ) 

I CharLiteral (char_lit ) 

I StringLiteral (string_lit ) 

! Enumerat ion (ident if ier) 

Sequence (expressions) 

SetLiteral (expressions) 

MapLiteral (expressions expression) 

TupleLiteral (pair_list) 

OneOfLiteral (pair) 



expressions : 

! 

i 

pair_list : 

I 

pair : 

integer_lit : 

real_lit : 

char lit : 



ExpressionsComp ( ) /* placeholder term */ 

ExpressionsNil () 

ExpressionsList (expression_list ) 

PairListComp ( ) /* placeholder term */ 

SinglePair (pair) 

Mult iPair (pair__list pair) 

PairBind (name_list expression) 

IntConstant ( INTEGER_LIT) 

RealConstant (REAL_LIT) 

CharConstant (CHAR LIT) 
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string_lit : 


St r ingConstant (STRING_LIT) 


! 

identifier : 


Identifier (IDENTIFIER) 



/* template commands */ 
transform inherits 



on "empty" 
on "addinherit" 


<inherits>: InheritNil ( ) , 

<inherits> : InheritStmt (<inherits>, cactual_name> , 

<hide>, <renames>) 


transform hide 

on "empty" 
on "addhide" 


chide > : HideNil () , 

<hide>: HideList (cname_list>) 


9 

transform renames 
on "empty" 
on "addrename" 


<renames>: RenameNilO, 

<renames> : RenameStmt (<renames>, Cidentif ier>, cident if ier>) 


S 

transform imports 
on "empty" 
on "addimport" 


<imports>: ImportNilO, 

<imports> : ImportStmt (<imports> / cname_list>, <actual_name> ) 


transform export 

on "empty" 
on "addexport" 


<export>: ExportNilO, 

<export>: Export Li st (Cname list>) 


transform where 

on "empty" 
on "addwhere" 


<where>: WhereEmpt y ( ) , 

<where> : WhereExp (<expression_list>) 


i 

transform concept 
on "type" 
on "value" 

9 


<concept> : Concept Type (cformal_name>, ctype_spec>, <where>) # 

<concept>: ConceptValue (cformal name> , <f ormal arguments>, 

<where> # <formal_arguments>, <where>) 



transform f ormal_parameter s 

on "empty" <formal_parameters> : FormalParmEmpty ( ) , 

on "fieldlist" <f ormal_parameters> : FormalParmList {<f ield_l ist> , <where> ) 

transform formal_arguments 

on "empty" <f ormal_argument s> : FormalArgEmpty ( ) , 



on "fieldlist" 


cformal arguments>: FormalArgList (cfield list>) 


/ 

transform field list 
on "single" 
on "multiple" 


cf ield_list> : SingleField (cf ield>) , 

cf ield_list> : Mult iField (cf ield_list>, cf ield>) 


transform field 

on "namelist" 


cfield>: FieldNameList ( cname_l ist> , ctype spec>) , 



on "collection" <field>: FieldCollect ion (<identif ier>, <type_spec>) 



transform type_spec 
on "named" 


ctype spec>: NamedType (cactual name>) 


transform name list 
on "single" 
on "multiple" 


cname_list> : Nameldent (cidentif ier>) , 

cname_l ist > : NamePair (Cname_list>, cidentif ier> ) 
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transform actual_parameter s 

on "empty" <actual_parameters> : 

on "arglist" <actual_parameters> : 

9 

transform actual_arguments 

on "empty" <actual_arguments> : 

on "arglist" <actual_arguments>: 



ActParmEmpty ( ) , 
ListOfArgs (<arg_list>) 



ActualArgNil ( ) , 
ActualArgList (<arg_list>) 



transform arg_list 
on "single" 
on "multiple" 



<arg_list>: SingleArg (<arg>) , 

<arg_list> : MultiArg <<arg_list>, <arg>) 



transform arg 

on "expression" <arg>: 
on "bindpair" <arg>: 



ArgExp (<expression>) , 
ArgPair (<pair>) 



transform expression_list 

<expression_list> : 
< express ion_li st > : 



on 


"single" 


on 


"mult iple 


7 

rm i 


expression 


on 


"quantify 


on 


"actname" 


on 


"0" 


on 


n ^ n 


on 




on 


" " 


on 


" implies " 


on 


"iff" 


on 


3 

A 

3 


on 


C 

A 

C 


on 




on 


3 

A 

II 

3 


on 


">»" 


on 


C 

II 

\ 

c 


on 




on 


" " 


on 




on 


e 

II 

A 

l 

C 


on 


3 

II 

II 

3 


on 


3 

I 

II 
II 


on 


"uminus" 


on 


" + " 


on 


fi ^ n 


on 


n * n 


on 


"/" 


on 


"mod" 


on 


ti * * n 


on 


"U" 


on 


"append" 


on 


" in_exp" 


on 


"star" 


on 


"collect" 


on 


"range" 


on 


"dot" 


on 


"[]" 


on 


"parens" 


on 


"measure" 


on 


"time" 



SingleExp (<expression>) , 

Mult iExp (<expression_list >, <expression>) 



<expression> : Quant i f ierExp (<quant if ier>, < f ield_list>, 

<rest rict ion>, <expression>) , 

<expression> : IdentExp ( <actual_name>, <actual_argument s>) , 

<expression>: At Exp { <actual_name> , <actual_name>, 

<actual_arguments>) , 

<expression> : NotExp (<expression> ) , 

<expression> : AndExp ( <expression> , < expression^ , 

<expression> : OrExp (<express ion> , <expression>) , 

<expression> : ImpliesExp (<expression>, <expression>) , 

<expression> : If fExp (<expression>, <expression> ) , 

<expression> : LessThan (<expression>, <expression>) , 

<expression> : GreaterThan ( <expression> , <expression> ) , 

<expression> : Equal ( <expression>, <expression>) , 

<expression> : LessEqual (<expression>, <expression> ) , 

<expression> : GreaterEqual (<expression>, <expression> ) , 

<expression> : NotEqual (<expression>, <expression> ) , 

<expression> : NotLessThan (<expression>, <expression> ) , 

<expression> : Not Greater Than (<expression> , <expression> ) , 

<expression> : NotLessEqual (<expression>, <express ion> ) , 

<expression> : NotGreaterEqual (<expression>, <expression>) , 

<expression> : Equivalent ( <expression> , <expression> ) , 

<expression> : NotEquivalent (<expression> , <expression> ) , 

<expression> : UnaryMinus (<expression> ) , 

<expressior.> : Add (<expression>, <expression> ) , 

<expression> : Subtract (<expression>, <expression> ) , 

<expression> : Multiply (< expressions <expression>) , 

<expression> : Divide (<expression> , <expression> ) , 

<expression> : ModExp <<expression> , <expression>) , 

<expression> : Exponent (<expression>, <expression> ) , 

<expression> : UExp (<expression>, <expression>) , 

<expression> : AppendExp (<expression>, <expression>) , 

<expression> : InExp (<expression> , <expression>) , 

<expression> : Star (<expression>) , 

<expression> : CollectExp (<expression>) , 

<expression> : RangeExp (<expression>, <expression> ) , 

<expression> : DotExp (<expression>, <identif ier>) , 

<expression> : SqBracketExp (<expression>, <expression>) , 

<expression> : ParenExp (<expression>) , 

<expression> : MeasureExp (<expression> , <ident if ier> ) , 

<expression> : TimeExpO, 
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on "delay" 
on "period" 
on "constant" 
on "lit_type" 
on "illegal" 
on "if then" 



<expression> : 
<expression> : 
<expression> : 
<expression> : 
<expression> : 
<expression> : 



DelayExp () , 

PeriodExp ( ) , 

Constant (<literal>) , 

LiteralType (<literal>, <actual_name>) , 

IllegalExp () , 

IfThen (<expression>, <expression>, <middle_cases> , 
<expression>) 



transform middle_cases 

on "empty" <middle_cases> : MidCaseNil ( ) , 

on "middle" <middle__cases> : MidCase (<middle_cases>, <expression>, <expression>) 



transform quantifier 




on 


"all" 


<quantifier> : 


on 


" some" 


<quantif ier> : 


on 


"number" 


<quantif ier> : 


on 


"sum" 


< quant if ier> : 


on 


"product" 


<quant if ier> : 


on 


"set" 


<quant if ier> : 


on 


"max" 


<quantifier> : 


on 


"min” 


< quant ifier> : 


on 


"union" 


< quant if ier> : 


on 


"intersect" 


< quant if ier> : 



All() , 

Some () , 

Number ( ) , 

Sum ( ) , 

Product ( ) , 
Set(), 

Maximum () , 
Minimum () , 
Union ( ) , 
Intersection () 



transform restriction 

on "empty" <restrict ion> : 

on "suchthat" <restrict ion> : 



transform literal 



on 


" int " 


<literal> : 


on 


"real_lit" 


<literal> : 


on 


"char_lit " 


<literal> : 


on 


"str_lit" 


<literal> : 


on 


"enum" 


<literal> : 


on 


"seq" 


<literal> : 


on 


"set " 


<literal> : 


on 


"map" 


<literal> : 


on 


"tuple" 


<literal> : 


on 


"one_of " 


<literal> : 


transform expressions 




on 


"empty" 


<expressions> 


on 


"explist " 


<expressions> 


transform pair_list 




on 


"single" 


<pair_list> : 


on 


"multi" 


<pair_list> : 



RestrictNil ( ) , 

SuchThat (<expression>) 



IntLiteral (<integer_lit > ) , 

RealLiteral (<real_lit>) , 

CharLiteral (<char_lit>) , 

StringLiteral (<string_lit>) , 

Enumeration (<identif ier>) , 

Sequence (<expressions> ) , 

SetLiteral (<expressions>) , 

MapLiteral (<expressions> , <expression>) , 
TupleLiteral (<pair_list>) , 

OneOfLiteral (<pair>) 

ExpressionsNil () , 

ExpressionsList (<expression_list > ) 



SinglePair (<pair>) , 

MultiPair (<pair_l ist > # <pair>) 
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B. LEXICAL PHYLA DECLARATIONS 



The file lexemes.ssl contains the declarations of the lexemes for the SPECDEF 
editor (i.e., the keywords, puncutation marks, and other special characters. 

/* File: LEXEMES.SSL */ 



/* 

/* This 


*/ 

file contains the lexeme declarations for the SPECDEF editor */ 


/* lexemes */ 
WHITESPACE: 


Whitespace< [\ \t\n]* >; 


AND: 

OR: 

NOT: 

IMPLIES: 

IFF: 


AndLex< " 4 " >; 
OrLex< " | " >; 
NotLex< >; 

ImpliesLex< "=>" >; 
If fLex< "<=>" >; 


GT: 

LT: 

LE: 

GE: 

NE: 

NLT: 

NGT : 

NLE : 

NGE: 

EQV : 

NEQV : 


GtLex< ">" >; 
LtLex< "<" >; 
LeLex< "<= n >; 
GeLex< ">=" >; 
NeLex< >; 

NltLex< >; 

NgtLex< n ->" >; 
NleLex< >; 

NgeLex< >; 

EqvLex< n == " >; 
NeqvLex< n ~== M >; 


RANGE: 

APPEND: 

MOD: 

EXP : 
BIND: 


RangeLex< >; 

AppendLex< "II" >; 
ModLex< "\\" > ; 
ExpLex< "**" >; 
BindLex< " : : " >; 


IF: 

THEN: 

ELSE: 

IN: 

U: 


I f Lex< n IF" >; 
T'nenLex< "THEN" >; 
El seLex< "ELSE" >; 
InLex< "IN" >; 
ULex< "U" > ; 


ALL: 

SOME: 

NUMBER : 

SUM: 

PRODUCT: 

SET : 

MAXIMUM: 

MINIMUM: 

UNION: 

INTERSECTION: 

SUCH: 

ELSE_IF : 


AlILex< "ALL" >; 

SomeLex< "SOME" >; 

NumberLex< "NUMBER" >; 

SumLex< "SUM" >; 

ProductLex< "PRODUCT" >; 

Set Lex< "SET" >; 

MaximomLex< "MAXIMUM" >; 
MinimumLex< "MINIMUM" >; 

UnionLex< "UNION" >; 

IntersectLex< "INTERSECTION" >; 
SuchLex< "SUCH" [ \ \t\n]+"THAT" >; 
Elself Lex< "ELSE"[\ \t\n]+"IF" >; 
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AS: 


AsLex< "AS" >; 


CONCEPT: 


ConceptLex< "CONCEPT" >; 


DEFINITION: 


DefnLex< "DEFINITION" >; 


DELAY: 


DelayLex< "DELAY" >; 


END: 


EndLex< "END" >; 


EXPORT: 


ExportLex< "EXPORT" >; 


FI : 


FiLex< "FI" >; 


FROM: 


FromLex< “FROM" >; 


HIDE: 


HideLex< "HIDE" >; 


IMPORT : 


Import Lex< "IMPORT" >; 


INHERIT: 


InheritLex< "INHERIT" >; 


PERIOD: 


PeriodLex< "PERIOD" >; 


RENAME: 


RenameLex< "RENAME" >; 


TIME: 


TimeLex< "TIME" >; 


VALUE: 


ValueLex< "VALUE" >; 


WHERE: 


WhereLex< "WHERE" >; 


SEMI: 


SemiLex< >; 


COMMA: 


CommaLex< "," >; 


PLUS: 


PlusLex< "+" >; 


MINUS: 


MinusLex< "-" >; 


MUL: 


MulLex< "*" >; 


DIV: 


DivLex< "/" >; 


UMINUS : 


UminusLex< "-" >; 


DOT: 


DotLex< "." >; 


STAR: 


StarLex< >; 


INTEGER_LIT : 


IntegerLex< [0-9]+ >; 


REAL_LIT: 


RealLex< [ 0- 9] +" . " [ 0-9] + >; 


CHAR_LIT : 


CharLex< [ A \n]"' " >; 


STRING_LIT: 


StringLex< [ " ] [ A " \\ ] * [ " ] >; 


IDENTIFIER: 


IdentLex< [a-zA-Z] [a-zA-Z_0-9] 



C. ATTRIBUTE DECLARATIONS 

The file attribs.ssl contains the attribute declarations and replacement rules for the 
concrete input syntax for textual input. 



/* File: ATTRIBS.SSL 

/* 

/* This file contains the attribute declarations for the concrete 

/* input syntax for the SPECDEF editor. 

/* association between abstract syntax and concrete input syntax */ 



Module 


{ syn 


module 


t; 


} 


Interface 


{ syn 


interface 


t; 


) 


Inherits 


{ syn 


inherit s 


t; 


) 


Hide 


{ syn 


hide 


t; 


} 


Renames 


{ syn 


renames 


t; 


} 


Imports 


{ syn 


imports 


t; 


} 


Export 


{ syn 


export 


t; 


) 


Where 


{ syn 


where 


t; 


) 


Concepts 


{ syn 


concept s 


t; 


} 


Concept 


c 

>i 

to 


concept 


t; 


} 


FormalName 


{ syn 


formal name 


t; 


} 



V 

*/ 

*/ 

*/ 
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FormalParm 


{ syn 


f ormal_paramet ers 


t; 


} 


Formal Arg 


{ syn 


f ormal_argument s 


t; 


} 


FieldList 


{ syn 


f ield_list 


t ; 


} 


Field 


{ syn 


field 


t; 


) 


TypeSpec 


{ syn 


type_spec 


t; 


} 


NameList 


{ syn 


name_l ist 


t; 


} 


ActualName 


{ syn 


actual_name 


t; 


} 


ActualParm 


{ syn 


actual parameters 


t; 


} 


ActualArgs 


{ syn 


actual arguments 


t ; 


} 


ArgList 


{ syn 


arg_list 


t; 


> 


Arg 


{ syn 


arg 


t; 


} 


ExpList 


{ syn 


expression_list 


t; 


} 


Exp 


{ syn 


expression 


t; 


} 


MiddleCases 


{ syn 


middle_cases 


t; 


} 


Quantifier 


{ syn 


quantif ier 


t; 


} 


Restriction 


{ syn 


restriction 


t; 


} 


Literal 


{ syn 


literal 


t; 


} 


Expressions 


{ syn 


expressions 


t; 


> 


PairList 


{ syn 


pair_list 


t; 


} 


Pair 


{ syn 


pair 


t; 


) 


IntegerLit 


{ syn 


integer_l it 


t ; 


) 


RealLit 


{ syn 


real_l it 


t ; 


} 


CharLit 


{ syn 


char_l it 


t ; 


} 


St r ingLit 


{ syn 


st r ing_l it 


t; 


} 


Ident 


{ syn 


identifier 


t; 


} 


/* replacement 


rules 1 


*/ 






module 


- 


Module . t ; 






interface 


- 


Interface . t ; 






inherits 


- 


Inherits . t ; 






hide 




Hide . t ; 






renames 


- 


Renames . t ; 






imports 


- 


Imports . t ; 






export 


- 


Export . t ; 






where 


- 


Where . t ; 






concept s 


- 


Concepts . t ; 






concept 


- 


Concept . t ; 






f ormal name 




FormalName . t ; 






formal_pararreters - 


FormalParm. t ; 






f ormal_argumen: 


: s - 


FormalArg . t; 






f ield_l ist 


- 


FieldList . t ; 






f iela 


- 


Field . t ; 






type spec 


- 


TypeSpec . t ; 






name list 


- 


NameList . t ; 






actual name 


- 


ActualName . t ; 






actual_parameter s - 


ActualParm. t ; 






actual_argument s - 


ActualArgs . t ; 






arg_list 


- 


ArgList . t ; 






arg 


- 


Arg. t; 






expression_lis: 


: ~ 


ExpList . t; 






expression 


- 


Exp. t ; 






middle__cases 


- 


MiddleCases . t ; 






quantifier 


- 


Quantifier . t; 






restriction 


- 


Restriction . t; 






1 iteral 


- 


Literal . t ; 






expressions 


- 


Expressions . t ; 






pair_list 


- 


PairList . t ; 






pair 


- 


Pair .t; 
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integer_lit 

real_lit 

char_lit 

string_lit 

identifier 



IntegerLit . t ; 
RealLit . t ; 
CharLit . t ; 

Str ingLit . t ; 
Ident . t ; 



D. PRECEDENCE RULES AND CONCRETE INPUT SYNTAX 

The file concrete. SSl contains the precedence and associativity rules for the concrete 
input syntax, plus all the concrete parsing declarations. 



/* File: CONCRETE. SSL */ 

/* */ 
/* This file contains the precedence and associativity declarations */ 

f* and the concrete input syntax parsing rules for the SPECDEF editor. V 

/* precedence and associat ivity declarations */ 

left IF IDENTIFIER SEMI; 

left ' , ' COMMA; 

left SUCH; 

left IFF; 

left IMPLIES; 

left ' | ' OR; 

left AND; 

left NOT; 

left '<' '>' LE GE NE NLT NGT NLE NGE EQV NEQV; 

nonassoc IN RANGE; 

left U APPEND; 

left PLUS MINUS; 

left ' ' /' MUL DIV MOD; 

left UMINUS ; 

left EXP; 

left ' (' ' { ' DOT WHERE; 

left STAR; 



/* concrete input syntax */ 

Module : := (DEFINITION Interface Concepts END) 

{Module. t = DefModuleDecl (Interface .t, Concepts .t) ; ) 

Interface ::= (FormalName Inherits Imports Export) 

{Interface. t = Inter faceDecl (FormalName . t , Inherit s . t , 
Imports.t, Export . t) ; ) 



Inherits : := () {$$.t = InheritNil ( ) ; ) 

I (INHERIT Inherits ActualName Hide Renames) 

{ Inherit s$l . t = InheritStmt (Inherits$2 .t, ActualName .t. 
Hide . t , Renames . t ) ; ) 



Hide 



0 {$$.t « HideNil () ; } 

(HIDE NameList) {Hide.t = HideList (NameList . t ) ; ) 



Renames : := () {$$.t = RenameNil ( ) ; } 

I (Renames RENAME Ident AS Ident) 

{RenamesSl.t = RenameStmt (Renames$2 . t, IdentSl .t, Ident$2 .t) ; } 
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Imports 


;:= () {$$.t = ImportNil () ; } 

| (Imports IMPORT NameList FROM ActualName) 

{Imports$l.t = ImportStmt (Imports$2 .t , NameList .t, ActualName .t) , 


Export 


: := () ($$.t - ExportNil () ; } 

| (EXPORT NameList) {Export. t = ExportList (NameList . t) ; } 


Where 


::= (prec SEMI) {$$.t = WhereEmpty ( ) ; } 

| (WHERE ExpList) {Where. t = WhereExp (ExpList . t ) ; ) 


Concepts 


::= (Concept) {Concepts. t = (Concept. t :: ConceptNil) ; ) 

| (Concept Concepts) 

{Concepts$l . t * (Concept. t :: Concepts$2 . t ) ; } 


Concept 


;:= (CONCEPT FormalName TypeSpec Where) 

{Concept. t = ConceptType (FormalName. t , TypeSpec . t , Where .t) ; ) 

| (CONCEPT FormalName FormalArg Where VALUE FormalArg Where) 

{Concept. t » Concept Value (FormalName . t , FormalArgSl . t, Where$l .t 
FormalArg$2 . t, Where$2 . t) ; } 


Forma IN ame 


: := (Ident FormaiParm) 

{ FormalName . t = FormName ( Ident . t , Forma lParm . t ); } 


FormaiParm 


::= () {$$.t = FormalParmEmpty ( ) ; } 

1 {' {' FieldList ' }' Where) 

{FormaiParm. t = FormalParmLi st (FieldList . t , Where . t) ; } 


Forma lArg 


::= () {$$.t = FormalArgEmpty ( ) ; } 

{ (' (' FieldList ' ) ' ) 

{FormalArg. t = FormalArgList (FieldList . t ); } 


FieldList 


(Field) {FieldList. t = SingleField (Field . t) ; } 

1 (FieldList ' , ' Field) 

{FieldLi st$l . t = MultiField (FieldList$2 . t. Field . t) ; ) 


Field 


::= ('?') {Field. t = UndefField ( ) ; ) 

(NameList TypeSpec) 

{Field. t = FieldNameList (NameList .t, TypeSpec. t) ; } 
('$' Ident TypeSpec) 

{Field. t * FieldCollect ion (Ident .t, TypeSpec. t) ; ) 


TypeSpec 


::= ( # ? # ) { TypeSpec . t = Unde f Type (); ) 

1 (ActualName) {TypeSpec. t = NamedType ( Actua iName . t ) ; } 


NameList 


(Ident) {NameList. t = Nameldent ( Ident . t ); } 

i (NameList ' , ' Ident) 

{NameList$l .t = NamePair (NameList $2 . t, Ident . t) ; } 


ActualName 


: := (Ident ActualParm) 

{ ActualName . t = ActualParmList ( Ident . t , ActualParm . t ); } 


ActualParm 


::= (prec SEMI) {$$.t - ActParmEmpty ( ) ; } 

1 ('{' ArgList '}') { ActualParm. t = ListOf Args ( ArgList . t ) ; ) 


ActualArgs 


: := (prec SEMI) {$$.t = ActualArgNi 1 ( ) ; ) 

1 (' (' ArgList ')') { ActualArgs . t = ActualArgList (ArgList .t) ; } 


ArgList 


: := (Arg) {ArgList. t = SingleArg ( Arg . t ) ; ) 

1 (ArgList ' , ' Arg prec COMMA) 

{ArgList$l.t = MultiArg (ArgList$2 .t , Arg. t) ; ) 
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Arg 

ExpList 

Exp 



(Exp) (Arg . t = ArgExp (Exp . t ) ; } 

(Pair) (Arg.t = ArgPair (Pair . t ) ; ) 



(Exp prec COMMA) (ExpList. t = SingleExp (Exp . t ) ; ) 

(ExpList Exp prec COMMA) 

(ExpList$l.t - Mult iExp (ExpList$2 .t,Exp.t) ; } 

{'?') (Exp.t *= UndefExpO;} 

(Quantifier ' (' FieldList Restriction BIND Exp ')') 

(Exp$l . t * Quantif ierExp (Quantifier .t, FieldList .t , 

Restriction . t, Exp$ 2 . t) ; } 

(ActualName ActualArgs) (Exp.t » IdentExp (ActualName .t , ActualArgs .t) ; } 
(ActualName '0' ActualName ActualArgs) 

(Exp.t = AtExp (Act ualNajne$l . t, Act ualName$2 .t, ActualArgs .t ); ) 

('-' Exp prec NOT) (Exp$l.t - NotExp (Exp$2 . t ) ; } 

(Exp Exp prec AND) (Exp$l.t - AndExp(Exp$2 .t,Exp$3 .t) ; } 

(Exp 'I' Exp prec OR) (Exp$l.t - OrExp (Exp$2 .t, Exp$3 . t) ; ) 

(Exp IMPLIES Exp prec IMPLIES) 

(Exp$l.t « ImpliesExp (Exp$2 .t,Exp$3 -t) ; } 

(Exp IFF Exp prec IFF) 

(Exp '<' Exp prec LE) 

(Exp '>' Exp prec LE) 

(Exp ' =' Exp prec '=') 

(Exp LE Exp prec LE) 

(Exp GE Exp prec LE) 

(Exp NE Exp prec LE) 

(Exp NLT Exp prec LE) 



If fExp (Exp$2 . t , Exp$3 . t ) ; } 
LessThan (Exp$2 . t , Exp$3 . t ) ; 



(Exp$l . t 
(Exp$l . t 

(Exp$l . t = Greater Than (Exp$2 . t , Exp$3 . t ) ; ) 
(Exp$l.t = Equal (Exp$2 . t, Exp$3 .t) ; } 

(Exp$l.t = LessEqual (Exp$2 . t , Exp$3 . t ) ; } 
(Exp$l.t = GreaterEqual (Exp$2 .t ,Exp$3 .t) ; ) 
(ExpSl.t = Not Equal (Exp$2 . t , Exp$3 . t ) ; } 

{ Exp$ 1 . t = Not LessThan (Exp$2 . t , Exp$3 . t ) ; } 

(Exp NGT Exp prec LE) 

(Exp$ 1 . t = Not Greater Than (Exp$2 . t , Exp$3 . t ) ; } 

(Exp NLE Exp prec LE) (Exp$l.t = NotLessEqual (Exp$2 . t , Exp$3 . t ) ; } 

(Exp NGE Exp prec LE) 

(Exp$l.t = NotGreaterEqual (Exp$2 . t, Exp$3 . t ) ; } 

(Exp EQV Exp prec LE) (Exp$l.t = Equivalent (Exp$2 . t , Exp$3 . t ); } 

(Exp NEQV Exp prec LE) (Exp$l.t = NotEquivalent (Exp$2 . t , Exp$3 . t ) ; ) 

(UMINUS Exp prec UMINUS) (Exp$l.t = UnaryMinus (Exp$2 . t ) ; ) 

(Exp$l.t = Add(Exp$2 .t,Exp$3 .t) ; ) 

(Exp$l.t - Subtract (Exp$2 .t, Exp$3 .t) ; } 
(Exp$l.t = Multiply (Exp$2 .t,Exp$3 .t) ; ) 
(Exp$l.t - Divide (Exp$2 . t, Exp$3 . t ); ) 

(Exp$ 1 . t = ModExp (Exp$2 . t , ExpS 3 . t ) ; } 
(Exp$l.t = Exponent (Exp$2 .t , Exp$3 . t ); ) 
(Exp$l.t = UExp (Exp$2 .t ,Exp$3 .t) ; ) 



(Exp Exp prec PLUS) 

(Exp Exp prec MINUS) 

(Exp Exp prec MUL) 

(Exp '/' Exp prec DIV) 

(Exp MOD Exp prec MOD) 

(Exp EXP Exp prec EXP) 

(Exp U Exp prec U) 

(Exp APPEND Exp prec APPEND) (Exp$l.t * AppendExp (Exp$2 . t , Exp$3 . t ) ; ) 



(Exp IN Exp prec IN) 

{' *' Exp prec STAR) 

(' $' Exp prec DOT) 

(Exp RANGE Exp prec RANGE) 
(Exp ' .' Ident prec DOT) 
(Exp ' [ ' Exp prec DOT) 

{' (' Exp ' ) ' ) 

(' (' Exp Ident ' ) ' ) 

(TIME) 

(DELAY) 

(PERIOD) 

(Literal ) 

(Literal 



(Exp$l.t = InExp (Exp$2 . t , Exp$3 . t ) ; ) 

{ Exp$ 1 . t = Exp$2.t;} 

Collect Exp (Exp$2 . t ) ; ) 
RangeExp (Exp$2 . t , Exp$3 . t ) ; } 
DotExp (Exp$2 . t , Ident . t ) ; ) 
SqBracketExp (Exp$2 . t , Exp$3 . 
ParenExp (Exp$2 . t ) ; ) 
MeasureExp (Exp$2 . t , Ident . t ) 



{Exp$ 1 . t 
(Exp$l . t 
{ Exp$ 1 . t 
{Exp$l . t 
(Exp$l.t 
(Exp$l .t 



t);} 

;) 



($$.t - TimeExpO;) 

(SS.t - DelayExpO;) 

($$.t = Per iodExp ( ) ; } 

(Exp.t = Constant (Literal .t) ; ) 
ActualName) 



(Exp.t = LiteralType (Literal .t, ActualName .t) ; } 

('!') ($$.t = IllegalExp ( ) ; } 

(IF Exp THEN Exp MiddleCases ELSE Exp FI) 

{ Exp$ 1 . t = IfThen (Exp$2 .t,Exp$3 . t , MiddleCases . t , Exp$4 



• t) ; ) 
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MidaleCases 



Quantifier 



Restriction 

Literal 



Expressions 

PairList 

Pair 

IntegerLit 

RealLit 

CharLit 

StringLit 

Ident 



I 



I 

I 

I 

I 

I 

I 

I 

I 

I 



I 

I 

I 

I 

I 

I 

I 

I 

I 



I 



I 



() ($$.t = MidCaseNi 1 ( ) ; } 

(MiddleCases ELSE_IF Exp THEN Exp) 

(MiddleCases$l . t = MidCase (MiddleCases$2 . t , Exp$ 1 . t , Exp$2 . t ); } 



(ALL) 

(SOME) 

(NUMBER) 

(SUM) 

(PRODUCT) 

(SET) 

(MAXIMUM) 

(MINIMUM) 

(UNION) 



($$.t 

($$.t 

($$.t 

($$.t 

($$.t 

($$.t 

($$.t 

($$.t 

($$.t 



AllO ;) 
Some ( ) ; } 
Number () ; } 
Sum ( ) ; } 
Product () ; 
Set();} 
Maximum ( ) ; 
MinimumO ; 
Union ( ) ; } 



(INTERSECTION) ($$.t = Inter sect ion (); 



0 

(SUCH Exp) 



($$.t = Restr ictNil () ; } 

(Restrict ion .t - SuchThat (Exp.t ) ; } 



(IntegerLit) 

(RealLit) 

(CharLit) 
(StringLit ) 

('#' Ident) 

( ' I ' Expressions ' 
( ' { ' Expressions ' 
( ' ( ' Expressions ' 

(' [' PairList ' ] ' ) 
(' {' Pair ' ) 



(Literal. t « IntLiteral (IntegerLit .t ); } 

(Literal. t *= RealLiteral (RealLit . t) ; } 

(Literal. t = CharLiteral (CharLit . t ); } 

(Literal. t = St ringLiteral (StringLit . t ); } 
(Literal. t = Enumeration (Ident . t) ; } 

]') (Literal. t = Sequence (Expressions . t ); } 

}') (Literal. t = SetLiteral (Expressions . t) ; } 

; ' Exp ' } ' ) 

(Literal. t = MapLiteral (Expressions . t , Exp . t ); } 
(Literal. t = TupleLiteral (PairList . t ); } 

(Literal. t = OneOf Literal (Pair . t ); } 



0 

(ExpList ) 



{$$.t = ExpressionsNi 1 () ; } 

(Expressions . t = ExpressionsList (ExpLi st . t ) ; } 



(Pair) (PairList. t = SinglePair (Pair .t) ; } 

(PairList Pair) (Pai rLi st$l . t = Mult iPair (PairList$2 . t , Pai r . t ) ; } 



(NameList BIND Exp) (Pair.t = Pai rBind (NameLi st . t , Exp . t ) ; } 
(INTEGER_LIT) ( IntegerLit . t = IntConstant (INTEGER_LIT) ; } 

(REAL_LIT) (RealLit. t = RealConstant (REAL_LIT) ; } 

(CHAR_LIT ) (CharLit. t = CharConstant (CHAR_LIT) ; } 

(STRING_LIT) (StringLit. t = StringConstant (STRING_LIT) ; } 

(IDENTIFIER) ( Ident. t = Ident i fier (IDENTIFIER) ; } 
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E. UNPARSING SCHEMES 



The file unparse.ssl contains the unparsing declarations for the display represen- 
tation of the constructs for the SPECDEF editor. 



/* File: UNPARSE.SSL 












*/ 


/* 














*/ 


/* This file 


contains the unparsing rules for the SPECDEF editor. 




*/ 


/* Unparsing Scheme 


*/ 














start : 


Spec 


[ 0 : 


: 0 


] 








spec : 


ModuleNi 1 


[ 0 : 


: ] 










\ 


ModulePair 


[ e : 


; : = 


A ["%n%n" ] 0 ] 








0 

module : 


DefModuleDecl 


[ 0 : 


: : = 


"DEFINITION "00 


" %n" 














"END" ] 








/ 

interface : 


InterfaceDecl 


[ e : 


: : = 


0 "%t" 000 "%b%n" ] 






inherits : 


Inher itNi 1 


[ A 


] 










1 


InheritPrompt 


[ A 


• 7 


"<inher it>" ] 








1 


Inher itStmt 


[ A 


: = 


0 "%n" " INHERIT " 0 


"%t" @ 


6 


" %b" ] 


0 

hide : 


HideNil 


[ A 


i 










1 


HidePrompt 


[ A 


: = 


"<hide>" ] 








1 


HideList 


[ A 


: = 


"%n" "HIDE " 0 ] 








renames : 


RenameNil 


[ A 


] 










i 


RenamePrompt 


[ A 


: = 


"<rename>" ] 








i 


RenameStmt 


[ A 


: = 


0 " %n" "RENAME " 0 " 


AS " 0 


] 




/ 

imports : 


ImportNil 


[ A 


] 










1 


ImportPrompt 


[ A 


: = 


"<import >" ] 








1 


ImportStmt 


[ A 


: = 


0 " %n" " IMPORT " 0 " 


FROM " 


0 


] 


0 

export : 


ExportNil 


[ A 


] 










i 


ExportPrompt 


[ A 


: = 


”<export>" ] 








i 


ExportList 


[ A 


: = 


" %n" "EXPORT " 0 ] 








where : 


WhereEmpty 


[ A 


] 










1 


WherePrompt 


[ A 


: = 


"<where>" ] 








1 


WhereExp 


[ A 




"WHERE " 0 ] 








concepts : 


ConceptNil 


[ e : 


: : = 


] 








1 


ConceptPair 


[ e i 


: ; = 


A 0 ] 








concept : 


ConceptComp 


t 0 : 


: 


" <concept>" ] 








1 


ConceptType 


[ A I 


: : = 


"%t%n" "CONCEPT " 0 


" : " 0 


(i 


%t %n" 










0 *%b%b%n" 


] 






1 


ConceptValue 


[ A : 


: : = 


"%t%n" "CONCEPT " 0 


n n 0 tt 


n 


0 " %t %n" 










"VALUE " 0 


" %n” 0 


"%b%b%n" ] 


0 

formal name : 


FormName 


[ A : 


: : = 


0 " " 0 ] 
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formal parameters : 


FormalParmEmpty 


l A : ] 




1 


F o rma 1 P a rmP r ompt 


[ " :: = 


: "<f ormal_parm>" ] 


1 


Forma lParmLi st 


[ A :: = 


= "[" 0 "} n 0 ] 


formal arguments : 


Forma lArgEmpty [ 


A : ] 




1 


Forma lArgPrompt [ 


A : 


"<formal_args>" ] 


1 


FormalArgList [ 


A . . j_ 


" r e ") " ] 


f ie ld_l 1st : 


FieldListComp [ 


A . . K 


"<field>" ] 


I 


SingleField [ 


A . 


0 ] 


1 


MultiField [ 


A . . e 


e ", * 0 ] 


9 

field : 


UndefField [ 


A . . E 


-?" ] 


1 


Fie ldNameList I 


A . . = 


0 " : " e ] 


1 


FieldCollection [ 


A , ;s 


0 " : ■ 0 ] 


s 

type_spec : 


UndefType [ 


A ; 


"?" ] 


1 


NamedType [ 


A ::= 


0 ] 


name^list : 


Nameldent [ 


A . • = 


6 ] 


1 


NamePair [ 


a • • = 


0 ", " 0 ] 


actual_name : 


ActualParmList [ 


A . . 


e n " e ] 


actual_parameters : 


ActParmEmpty [ 


A : 1 




1 


ActParmPrompt [ 


A , , = 


"<actual_parm>" ] 


1 


ListOfArgs [ 


A ;J - 


" { " 0 " } ■ ] 


actual_argument s : 


ActualArgNil [ 


A : ] 




1 


ActualArgPrompt [ 


A : : = 


"<actual_arg>" ] 


1 


ActualArgList [ 


A . • — 


" (" 0 " ) " ] 


arg_list : 


ArgListEmpty [ 


A . . _ 


"<arg>" ] 


1 


SingleArg [ 


a : : = 


0 ] 


1 


MultiArg [ 


A , , _ 


0 ", " 0 ] 


arg : 


ArgComp [ 


A . . = 


n <arg>" ] 


1 


ArgExp [ 


A • • = 


0 ] 


1 


ArgPair ( 


A « • ^ 


0 ] 


expression list : 


EmptyExpList [ 


A ; ; = 


^expression list>" ] 


1 


SingleExp [ 


A : : = 


0 ] 


1 


MultiExp [ 


a ; ; = 


0 ", " 0 ] 


expression : 


UndefExp [ 


A . . _ 


" ?” ] 




Quant i fierExp [ 


A . . _ 


n %{" 0 " r 0 "%o n 0 -%}% [%o 




laentExp [ 


A . 


0 0 ] 


1 


AtExp [ 


A ... 


0 "0" 0 0 ] 


1 


NotExp [ 


A . 


0 ] 


1 


AndExp [ 


A : : = 


"%{" 0 "%[%o & " 0 "%]%}" ] 


1 


OrExp [ 


A J ; = 


"%{" 0 "%[%o | " 0 "%]%}" ] 


1 


ImpliesExp [ 


A . 


"%{" 0 "%[%o => n 0 "%]%}" ] 


1 


IffExp [ 


A . . _ 


"%{" 0 "% [lo <«> " 0 "%]%)" 


1 


LessThan [ 


A . . = 


-%{" 0 "%[%o < " 0 "%]%}" ] 


1 


GreaterThan [ 


a ; 


"%(" 0 "% [%o > " 0 "%]%}" ] 


1 


Equal [ 


A . .. 


"%{" 0 "%[%o - " 0 "%]%}" ] 


1 


LessEqual [ 


A . ; = 


"%{" 0 "%[%o <= " 0 "%]%)" ] 


1 


GreaterEqual [ 


A ; ; = 


n %{" 0 "%[%o >= " 0 *%] % } n 3 


1 


NotEqual [ 


A J ; = 


"%{" 0 "%[%o ” 0 "%]%)" ] 


1 


NotLessThan [ 


A . 


"%{" 0 "%[%o ~< " 0 "%]%)" ] 


! 


NotGreaterThan [ 


A . . _ 


"%{" 0 -%[%o ~> " 0 "%]%) n ] 
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middle cases 



quantifier 



restrict ion 



literal 



NotLessEqual 

NotGreaterEqual 

Equivalent 

NotEquivalent 

UnaryMinus 

Add 

Subtract 

Multiply 

Divide 

ModExp 

Exponent 

UExp 

AppendExp 

InExp 

Star 

CollectExp 

RangeExp 

DotExp 

SqBracketExp 

ParenExp 

MeasureExp 

TimeExp 

DelayExp 

PeriodExp 

Constant 

LiteralType 

IllegalExp 

IfThen 



:="%{" @ "% (%o ~<= " @ "%]%}" ] 

"%{" 0 "% [%o ->- " 0 "%]%}" ] 

; = -%r 0 "%[%o == " e "%]%r ] 

:= "%{" 0 -%[%o " 0 "%]%}" ] 

@ ] 

:« @ " + " 0 ] 

:« 0 " - ■ 0 ] 

0 " * " 0 ] 

0 " / " 0 ] 

0 " \\" 0 ] 

:« 0 "**« 0 ] 

•%{" § ** % [ % o U " 0 "%]%}" ] 

;« «%{" 0 "%[% 0 || "0 "%]%}" ] 

:« -%(• 0 -%[%o IN " 0 "%]%}" ] 

:« 0 ] 

:* -$• 0 ] 

:« 0 0 ] 

:« 0 0 ] 

:« 0 "[• 0 "]" ] 

:* "(" 0 ")" ] 

• _ " (" 0 0 "j " ] 

"TIME" ] 

"DELAY" ] 

"PERIOD" ] 

0 ] 

:« 0 "0" 0 ] 

" ! " ] 



:= "% { "" IF " 
0 



0 "%t%o%b THEN " 0 " %t %o%b" 
" %t%o%b ELSE " 0 " FI% } " ] 



MidCaseNil 

MiddlePrompt 

MidCase 



A : ] 

A ::= "<middle_cases>" ] 

A "%{" 0 "%o ELSE IF " 0 "%o THEN " 0 "%}" ] 



Quant if ierComp 

All 

Some 

Number 

Sum 

Product 

Set 

Maximum 

Minimum 

Union 

Intersection 



A : := "<quantif ier>" ] 
A : "ALL" ] 

A : "SOME" ] 

A : "NUMBER" ] 

A : "SUM" ] 

A : "PRODUCT" ] 

A : "SET" ] 

A : "MAXIMUM" ] 

A : "MINIMUM" ] 

A : "UNION" ] 

A : "INTERSECTION" ] 



Rest rictComp 

RestrictNil 

SuchThat 



A "<restrict ion>" ] 

A ::= ] 

A ::= * SUCH THAT " 0 ] 



EmptyLiteral 

IntLiteral 

RealLiteral 

CharLiteral 

StringLiteral 

Enumerat ion 

Sequence 

SetLiteral 



"<liter al>" 



0 1 
0 ] 

0 ] 

0 ] 
"#" 0 
"(• 0 
"{" 0 



] 

"]" ] 
] 



] 
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1 MapLiteral 

1 TupleLiteral 

1 OneOfLiteral 


expressions 


* 

: ExpressionsComp 

1 ExpressionsNil 

1 ExpressionsList 


pair_list 


: PairListComp 

I SinglePair 

I MultiPair 


pair 


PairBind 


integer lit 


IntConstant 


real_lit 


RealConstant 


char_l it 


CharConstant 


string lit 


St ringConstant 


identifier 


Identifier 



"{" 0 ";" 0 n }"] 

" [" 0 "] " ] 

" { " 0 " } " ] 

"<expressions>" ] 

] 

e ] 

"<pair_list>" ] 

e ] 

0 ", " 0 ] 

0 " " 0 ] 



A ] 
A ] 
A ] 
A ] 
A 3 
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APPENDIX C 



L USER S MANUAL FOR THE SPECDEF EDITOR 

The SPECDEF editor is a syntax directed editor for writing Spec specification 
language definition modules. A syntax directed editor, also known as a language-based 
editor, is one in which the programs and systems are created and modified according to 
the syntactic structure of the language. The programs are represented internally as 
abstract syntax trees, or parse trees, that are built by the editor through constructive 
commands entered by the user. 

The "programs" that are manipulated in the SPECDEF editor are actually specifi- 
cations, not compilable programs. However, the Spec language has a very well-defined 
syntactic structure, just like most programming languages, so a syntax directed editor 
works just as well for Spec as it does for any structured programming language. 

The SPECDEF editor uses the principle of immediate computation to analyze the 
syntactic correctness of the abstract syntax tree as it is being constructed. This means 
that as the user enters each additional component to the parse tree, or modifies an existing 
component, the entire tree is re-analyzed to see if the addition or modification maintains 
a correct syntactic structure. If it does not, the user is immediately signalled that a syntax 
error has occurred, which must be corrected before the editor will allow the user to add 
any more components. In this way, the editor ensures that only syntactically correct (i.e., 
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error-free) specifications are written. This is the key feature of any syntax directed 
editor. 

This editor was created using the Synthesizer Generator, a CASE tool for generating 
syntax directed editors from an editor specification file containing the grammar rules (the 
abstract syntax), the display representation (known as the unparsing scheme), and the 
concrete input syntax rules of the language for which the editor is designed, in this case 
Spec. 

A. STANDARD FEATURES 

Each editor specification results in an editor with distinct characteristics that are 
language-dependent. However, there is a generic user interface common to all editors 
created by the Synthesizer Generator. A few of the interface features have minor 
differences dependent on the windowing system for which the editor is targeted. These 
differences are indicated where applicable. 

Throughout this user’s manual, editor system commands are written in boldface. 
Many of these commands have one or more key-bindings, which are indicated by the text 
between angle brackets (e.g., < A l or ESC-x >). These are keys on the keyboard that will 
invoke the commands. The symbol A refers to the CTRL key, which must be held down 
while depressing the key indicated immediately following the A symbol. For example, 
A C means "hold down the CTRL key and depress the C key". 

The display screen of the editor will normally have some portion of the displayed text 
highlighted in reverse-video. In the diagrams that follow, characters that would appear in 
reverse- video on the actual display are written in boldface. 
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1. Invoking and Exiting the Editor 

The editor is invoked by typing the name SPECDEF (or SPECDEF_SUN for the 
Sun workstation version of the editor) at the operating system prompt with an optional 
list of arguments consisting of one or more filenames of files to be loaded into the editing 
buffers. Note that the editor name must be: typed in all capital letters. Invoking the editor 
with no arguments causes editing to begin in the default buffer main with no associated 
file. [Ref. 11: p. 90] 

To terminate an editing session, leave the editor and return to the operating 
system, the exit command < A C, ESC- A C, or A X A C > is executed. [Ref. 11: p. 91] 

2. Display Screen 

The editor’s display screen is divided into four horizontal stripes, or regions, 
labelled from top to bottom, the title bar, the command line, the object pane, and the help 
pane, as shown in Figure 22. The title bar is always highlighted and contains the name of 
the current buffer displayed in the object pane. The command line echos commands and 
error messages. The object pane displays all or a fragment of the current buffer’s 
contents. The help pane, which takes up the last few lines of the display window, lists 
the currently selected constituent, or node in the parse tree, plus the currently enabled 
template transformations, if any. [Ref. 10: p. 21; 11: p. 91] 

It should be noted that the horizontal lines separating the panes in all the diagrams 
of this user’s manual are for explanation purposes only. They do not appear on the actual 
video display terminal. The entire title bar, however, is always highlighted. 
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Figure 22 

Display screen regions 



On the Sun workstation version of the editor, the window will also have two 
scroll bars for use with the mouse: one to the right of the object pane and one below the 
object pane. These scroll bars control which portion of the buffer is visible in the object 
pane. [Ref. 1 1: p. 91] 

3. Current Selection vs. Locator 

SPECDEF is a screen-oriented hybrid structure editor, since it permits editing the 
structure of the displayed object through template insertions as well as allowing 
character- and line-oriented operations on the text A template of a component consists 
of a pattern of keywords and placeholders where additional components can be inserted. 
A Spec specification is created top down by invoking template transformations that insert 
new components within the framework of previously entered templates. These template 
transformations are the constructive commands that actually build the abstract syntax 
tree. [Ref. 10: pp. 21,26] 
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The current selection indicates the individual component of the specification at 
which the editor is positioned. This is indicated on the screen display by highlighting all 
components contained within the template of the current selection. The help pane also 
tells the user which component is currently selected by displaying the message 
"Positioned at <component>" , where <component> is the phylum name of the 
current selection. (A phylum can be thought of as a node in the abstract syntax tree.) 
[Ref. 10: p. 21] 

A character selection is displayed during text editing, indicating the specific 
character position within the highlighted selection where the next character can be 
entered. On standard video display terminals, this position is denoted by an unhigh- 
lighted character within the highlighted selection; on Sun workstations, the character 
selection is indicated by an I-beam symbol within the highlighted selection. [Ref. 10: pp. 
22,26] 

The locator can be used to change the current selection and the character 
selection. On standard video display terminals, the locator is the terminal’s cursor, 
generally denoted by a blinking underbar or a blinking solid box. The locator can be 
moved with the commands pointer-up < ESC-p >, pointer-down < ESC-d >, pointer- 
left < ESC-b >, and pointer-right < ESC-f >. Even after the locator is moved to a new 
component, the new selection is not made until the select command < ESC-@ > is 
executed. 
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• CAUTION: The locator does not automatically move to the new selection if the 
user changes selection by executing the forward-with-optionals command < A M 
or RETURN >. This can be very confusing to the user, since the cursor position 
will not correspond to the actual position in the parse tree structure of the object 
being edited. 

On Sun workstations, the locator is denoted by an arrow. The locator’s position is 
changed by moving the mouse, and the select command is executed by clicking the 
mouse’s selection button (the left button). [Ref. 10: pp. 22,300] 

B. TEXT ENTRY 

Selections are displayed according to the unparsing schemes, or display templates, 
declared in the editor specification. Each production in the grammar has its own 
template. The template for each selection is either editable as text or it is immutable. 
Note that a selection declared as immutable may have elements within its template that 
are not immutable. The selection must be moved to the editable part before text entry is 
permitted. [Ref. 10: pp. 22-23] 

If the current selection is not editable as text, any attempt to type a character is 
rejected by the editor, sounds a warning signal, and displays the message "text entry not 
permitted here" on the command line, as shown in Figure 23. The selection must be 
changed to an editable component by either repositioning the locator and executing the 
select command < ESC-@ >, or by executing one of the other structural selection by 
traversal commands, such as forward-preorder < A N >, backward-preorder < A P >, 
forward-with-optionals < A M or RETURN >, forward-sibling < ESC- A N >, forward- 
sibling-with-optionals < ESC- A M >, etc. (See Chapter 3 of [Ref. 11] for other 
structural selection by traversal commands.) [Ref. 10: pp. 22-24; 1 1: pp. 101-102] 
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Figure 23 

Example of illegal attempt to enter text 



When the current selection is editable, the entered text is captured into the text buffer , 
which is displayed in its proper position in the object pane. During editing, the selection 
does not exist as structure, but instead exists as text. Operations within the selection are 
defined on individual characters rather than on the structure. The text entry is terminated 
by executing forward-with-optionals < A M or RETURN >, at which time syntactic 
correctness is checked. [Ref. 10: p. 26] 

If a syntax error is detected, a warning signal sounds, the message "syntax error" 
appears on the command line, and the character selection is positioned at the last 
character of the leftmost error that was detected. For example, in Figure 24, an attempt 
was made to enter (p : passenger) as a formal argument to concept waiting, but the left 
and right parentheses were not entered, resulting in a syntax error. [Ref. 10: p. 27] 
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Figure 24 

Example of a syntax error 



To correct a syntax error, the user can either delete the entire text buffer by executing 
the command delete-selection < A K > and then entering the correct text, or the text 
buffer itself can be edited with any of a variety of commands described below. There 
will be one character highlighted within the text buffer. This character selection can be 
moved with the commands right < A F >, left < A B >, beginning-of-line < A A >, or end- 
of-line < A E >. Once the character selection is at the desired position, the user can either 
type additional characters to be inserted, or delete unwanted characters. Deletion 
commands are delete-next-character < A D > (which actually deletes the currently 
highlighted character), delete-previous-character < DEL > (which deletes the character 
to the left of the cursor), erase-to-end-of-line < ESC-d >, or erase-to-beginning-of-line 
< ESC-DEL >. [Ref. 11: pp. 103-104,109] 
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C. TEMPLATE INSERTION 



When a new selection is made, the help pane is updated to indicate which component 
is selected and any template transformations that are enabled. The template names listed 
are actually commands used to invoke the respective transformations. [Ref. 10: p. 23] 

Templates may be selected in three ways, dependent on which type of terminal is 
being used. On standard video display terminals, the user must escape to the command 
line by invoking the execute-command command < A l, TAB, or ESC-x >, and then 
typing a sufficient number of characters of the desired template name to make the choice 
unambiguous. If the prefix is ambiguous because an insufficient number of characters 
are typed, the message "<prefix> is ambiguous" appears on the command line, where 
<prefix> is the string that the user entered, as shown in Figures 25 and 26. On Sun 
workstations or other mouse-equipped workstations, transformations can be invoked by 
clicking on the transformation-name in the help pane, or by choosing from a pop-up 
menu of choices with the mouse’s structure-menu button (the right button). [Ref. 10: p. 
23; 11: p. 147] 

In the SPECDEF editor, it is recommended to expand the size of the help pane by two 
lines to be able to view all the possible transformations available for the phylum 
expression. This is accomplished by executing the enlarge-help < ESC- A Xz > 
command twice (once for each line of expansion). The default size of the help pane is 
four lines, but phylum expression requires six lines, as shown in Figures 25 and 26. 
[Ref. 11: p. 98] 
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Current buffer : main 



COMMAND: if 



DEFINITION waiting_passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger) 

VALUE (b : boolean) 

WHERE ALL(p : passenger , f : floor ?) 
<concept> 

END 



Positioned at expression 


quantify 


1 


implies 


iff 


< 




~< 


~> 


~<= 


+ 


- 


* 


/ 


in_exp 


star 


collect 


range 


time 


delay 


period 


constant 



actname 


@ 


- 


& 


> 


= 


<= 


>= 


~>= 


= = 


= = 


uminus 


mod 


** 


U 


append 


dot 


n 


parens 


measure 


lit type 


illegal 


if_then 





Figure 25 

Ambiguous template transformation selection 



Current buffer : main 



if is ambiguous 



DEFINITION waiting_passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger) 

VALUE (b : boolean) 

WHERE ALL(p : passenger , f : floor ?) 
<concept> 

END 



Positioned at expression 


quantify 


actname 


@ 


- 


& 


1 


implies 


iff 


< 


> 


* 


<= 


>= 




~< 


~> 


~<= 


~>= 


mx 




uminus 


+ 


- 


* 


/ 


mod 


• * 


u 


append 


in_exp 


star 


collect 


range 


dot 


D 


parens 


measure 


time 


delay 


period 


constant 


lit_type 


illegal 


ifjhen 





Figure 26 

Result of ambiguous transformation selection 
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Some selections do not have any associated template transformations. This is 
reflected in the help pane by listing only the current constituent. If an attempt is made to 
initiate a template insertion when no transformations are enabled, or an attempt is made 
to select a transformation other than those enabled, as in Figure 27, the editor will sound 
a warning signal, display the message "<template-name> is unknown command", 
where <template-name> is the character string typed by the user, and a help buffer will 
be displayed listing all the system commands and their associated key-bindings available 
at that location, as in Figure 28. The help buffer can be removed from the screen with the 
delete-other-window command < A X1 >. [Ref. 10: p. 25] 



Current buffer : main 


COMMAND: forall 


DEFINITION waiting passenger 
INHERIT elevator 
INHERIT passenger 




CONCEPT waiting (p : passenger ) 

VALUE (b : boolean ) 

WHERE <quantifler>(<field><restriction> :: ?) 
<concept> 

END 




Positioned at quantifier all some number sum 

set max min union intersect 


product 


Figure 27 

Attempt to initiate non-available transformation 



The forward-with-optionals command < A M or RETURN > advances the selection 
forward to the next component in preorder when executed alone, including stopping at 
any optional placeholder inserted by the editor, such as in a list. However, when entering 
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text or invoking a template transformation, the forward-with-optionals command 
behaves differently. When a transformation is invoked, the selection moves to the first 
placeholder (excluding optionals) in the transformed component. If no such placeholder 
exists, then the selection remains at the same position where the transformation was 
invoked. In such instances, it appears to the user that the forward-with-optionals 
command must be executed twice to advance to the next selection. [Ref. 10: pp. 37-38] 



Current buffer : main 



forall is unknown command 



DEFiNiTION waiting_passenger 
INHERIT elevator 
INHERIT passenger 



Positioned at quantifier all some number sum product 

set max min union intersect 



Current buffer : Help 



advance-after-transform 


(none) 


advance-after-parse 


(none) 


apropos 


<ESC ?> 


ascend-to-parent 


<ESC\> 


backward-preorder 


< A P> 


backward-sibling 


<ESC A P> 


backward-sibiing-wlth-optlonals 


<ESC A B> 


backward-wlth-optionals 


< A H> 


beginning-of-fiie 


<ESC <> 


beginnlng-of-line 


< A A> 



Figure 28 

Unknown Command message and Help buffer 
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D. SAVING AN EDITING SESSION 



Edited objects are contained in a named bujfer, such as the main buffer. To save the 
object being edited, the buffer contents must be written to a file. The command used to 
write such a file depends on whether the object was created directly during the current 
editing session, or if it was a previously existing file loaded into the buffer as an 
argument file when the editor was invoked, or was loaded with the command read-file 
file-name < A X A F or A X A R >. [Ref. 11: 95-97] 

There are two file formats in which an object may be saved: text or structure. A text 
file contains the display representation of the object as it would be viewed in the object 
pane. A structure file contains the internal representation of the edited object. [Ref. 1 1 : 
P- 95] 

An object that was saved as a structure file can be read back into the editor for re- 
editing. The unparsing schemes that were in effect at the time the file was written are 
restored, since they are saved as part of the file in these formats. A text file, however, 
can only be read into the editor if it can be reparsed, because the unparsing schemes in 
effect at the time the file was written are not saved as part of the file. If the text file 
contains syntactic errors, the file is read into the text buffer and the character selection is 
positioned near the error. This would occur in the case w'here the user saved a file 
immediately after attempting a syntactically incorrect text entry but before correcting the 
error. [Ref. 11: p. 96] 

When a previously existing file is read into a buffer, the format of the file becomes 
associated with the buffer for subsequent write-current-file commands < A Xs >. This 
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command writes the current modified contents of the buffer back to the same file using 
the same format as when the file was read into the buffer. [Ref. 11: p. 97] 

If the edited object was created during the current editing session, or if the user 
desires to save a previously existing file in a different format, execute the command 
write-named-file file-name format < A X A W >. The default format is structure. A pop- 
up window appears at the bottom of the display screen. This window contains parameter 
fields for the user to enter the filename of the file to save the buffer contents into, and the 
format in which to save it. When the user wants to save his work for later re-editing, the 
structure format should be selected. If the user wants to print the contents of the buffer, 
the file should be saved as a text file, which can then be printed as any regular text file. 
An example of this pop-up window is shown in Figures 29 and 30. Once the parameters 
are selected, the command start-command < ESC-S > must be executed to actually 
write the contents to the file. When the editor is done writing the file, the message 
"Wrote <filename>" is displayed on the command line, where <filename> is the name 
of the file being written, and the parameters window disappears. [Ref. 1 1: pp. 93,97] 
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Current buffer : main 



DEFINITION waitin g p assenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger ) 
VALUE (b : boolean ) 

WHERE ALL(<field><restriction> :: ?) 
<concept> 

END 



—Current Form : Write File Form 

I I 

|WRITE FILE: <flle-name> FILE FORMAT: structure | 

j Positioned at _file_name | 



Figure 29 

Pop-up write-named-file parameter window 



Current buffer : main 



DEFINITION waiting_passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger ) 
VALUE (b : boolean ) 

WHERE ALL(<field><restriction> :: ?) 
<concept> 

END 



—Current Form : Write File Form 

|COMMAND: text | 

|WRITE FILE: pass_def.spec FILE FORMAT: structure | 

(Positioned at _file_type text structure I 



Figure 30 

Specifying text format for Write File Form 
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E. EDITOR SYSTEM COMMANDS 



Many of the editor system commands are similar or identical to EMACS text editor 
command names and standard key-bindings [Ref. 11: p. 90]. The more commonly used 
commands have been described in the proceeding sections and are summarized below. 
There are numerous other less commonly used commands. Appendix D contains a 
complete list of the available editor commands. For a full description of each command, 
the reader is referred to Chapter 3 of The Synthesizer Generator Reference Manual [Ref. 
11 ]. 

1. Executing Commands and Transformations 

Every editor command has a name and zero or more key-bindings. There are four 
ways to invoke a command. First, the keystrokes bound to the command may be typed. 
Second, the command may be selected from a menu. Third, the command name may be 
typed on the command line of a window. And lastly, on mouse-equipped systems only, a 
mouse click may select an actuator bound to the command. All keystrokes other than the 
command key-bindings or escaped text entered on the command line are interpreted as 
textual insertions into the object being edited. [Ref. 11: p. 91] 

The following commands are used to execute transformations or to get out of the 



editor: 

• exit < A C, ESC- A C, A X A C >: Leave the editor and return to the shell. If any 
buffers have been modified since their associated files were last written out, a 
warning is issued in a pop-up window. To abort the exit, execute as cancel- 
command < ESC-C >. To continue with the exit command, execute a start- 
command < ESC-s >. 
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• execute-command name < A l, ESC-x >: Initiates the command mode and 

redirects subsequent characters to the command line following the prompt 
COMMAND:. Entry on the command line is terminated by the first blank, 
carriage return, or other command key-binding. The command name need not be 
typed in its entirety; any prefix of a command that uniquely identifies the 
command is sufficient Transformations take priority over built-in commands. If 
the command has no parameters, it is executed immediately. Otherwise, a pop- 
up window for parameters appears; after the parameters have been provided, the 
command should be initiated by executing start-command. If a command 
parameter is either invalid or ambiguous, an error message is issued. Note that 
the control character A l is TAB. 

• start-command < ESC-S >: Initiate execution of a command with the 

parameters contained in the current pop-up parameter form window. If not 
currently editing a parameter form, start-command does nothing. 

2. Buffers, Selections, and Files 

Objects that are being manipulated in the editor are contained in a collection of 
named buffers. Each file being edited is typically read into a distinct buffer. The buffer 
is then associated with the given file until either a different file is read into that buffer, or 
the given buffer is written out to a different file. [Ref. 1 1: p. 95] 

Two file formats are supported: text and structure. Text files contain the display 
representation of a term. Structure files contain an internal representation of a term. A 
term is a derivation tree of the object being manipulated. [Ref. 1 1 : p. 95] 

Terms written as structure files can be read back into the editor with the identical 
structure as when the file was saved. Text files, however, can only be read back into the 
editor if the text can be reparsed because the unparsing schemes in effect at the time the 
file was written are not saved within the file. [Ref. 11: p. 96] 
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The following commands are used to read or write files: 

• read-file file-name < A X A F, A X A R >: Reads the named file into the current 
buffer, deleting the previous contents of that buffer. The buffer becomes 
associated with that file for subsequent write-current-file commands. If the 
current buffer is already associated with a file that has not been written since the 
buffer was last updated, you must answer yes to the question Overwrite buffer? 
before the read will be executed. If the given file is text, it must be syntactically 
correct with respect to the input syntax of the given editor. If syntactically 
incorrect, the file is read into the text buffer with the cursor positioned near the 
error. If the given file is a structured file, the term contained in the file and the 
term currendy contained in the buffer must be in the same phylum. 

• write-current-file < A Xs >: Write the value of the buffer displayed in the 
current window to its associated file in the current format associated with the 
buffer. 

• write-named-file file-name format < A X A W >: Write the value of the buffer 
displayed in the current window to the given file in the given format The 
default format--structure--can be changed by selecting the format field of the 
pop-up parameter window and invoking the text transformation. 

3. Creating, Deleting, and Resizing Windows and Panes 

In editors generated for standard video display terminals, windows are non- 
overlapping, are arranged in horizontal stripes across the screen, and are cyclicly ordered 
from top to bottom for the purpose of the next-window and previous-window 
commands. [Ref. 1 1 : p. 97] 

In editors generated for workstations with high-resolution, bitmapped displays 
(e.g.. Sun workstations), resizable and overlapping windows with scroll bars are 
supported. [Ref. 1 1: p. 98] 

The following commands manipulate the windows and display: 

• delete-other-windows < A X1 >: Delete all windows other than the current one. 

• next-window < A Xn >: Switch to the next window on the screen. (Video 

display terminals only.) 
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• previous-window < A Xp >: Switch to the previous window on the screen. 

(Video display terminals only.) 

• enlarge-help < ESC- A Xz >: Increase the size of the help pane of the current 
window by one line. 

• redraw-display < A L >: Refresh the screen image to remove any spurious 

characters. 

4. Changing the Structural Selection by Traversal of the Edited Term 

The current selection can be changed by moving through the structure of the 
abstract-syntax tree (e.g., in preorder, reverse preorder, by moving to the parent, etc.). If 
such a motion would cause the selection to leave the currently displayed text in the 
window, the object is scrolled automatically to keep the new selection within the 
window. [Ref. 11: p. 101] 

Some commands cause the editor to automatically insert instances of optional 
components into the abstract syntax tree (e.g., forward-with-optionals < A M or 
RETURN >). The placeholder for an optional element becomes the current selection. If 
the selection is advanced beyond an inserted optional element, and that optional element 
is still only a placeholder, that placeholder is removed from the abstract syntax tree (and 
consequently from the display). Other commands that change the selection ignore any 
optional components and therefore do not insen an instance of such elements in the 
abstract syntax tree. [Ref. 1 1: p. 101] 

The following commands are used to move the selection: 

• forward-preorder < A N >: Change the selection to the next resting place in a 
forward preorder traversal of the abstract-syntax tree. Do not stop at place- 
holders for optional constituents. 
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• backward-preorder < A P >: Change the selection to the previous resting place 
in a forward preorder traversal of the abstract-syntax tree. Do not stop at 
placeholders for optional constituents. 

• right < A F >: If there is no text buffer, right is the same as forward-preorder. 

See Section I.E.5 for the meaning of right when there is a text buffer. 

• left < A B >: If there is no text buffer, left is the same as backward-preorder. 
See Section I.E.5 for the meaning of left when there is a text buffer. 

• forward-with-optionals < A M >: Change the selection to the next resting place 
in a forward preorder traversal of the abstract-syntax tree. Stop at placeholders 
for optional constituents. Note the A M is RETURN. 

• end-of-file < ESC-> >: Change the selection to the rightmost resting place in 
the abstract syntax tree. 

5. Changing the Character Selection by Traversal of the Text Buffer 

The text buffer contains text being entered or re-edited. This buffer is displayed 
in its proper position within its enclosing structural context. One character within the 
text buffer is selected, shown by a highlight. This character selection can be moved 
within the text buffer by normal horizontal and vertical "cursor- motion" commands. If 
the character selection is moved beyond the boundaries of the text buffer, the contents of 
the text buffer are submitted for syntactic analysis and translation. Within the text buffer, 
the structural-motion commands forward-preorder, backward-preorder, right, and 
left, which were previously defined for moving the component selection, have been 
overloaded and are also used to move the character selection down, up, right, and left, 
respectively. [Ref. 11: p. 103] 
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The following commands are used to change the character selection within the 
text buffer: 

• forward-preorder < A N >: Move the character selection one position down. If 
already at the last line of the text buffer, this command is inteipreted as forward- 
after-parse. 

• backward-preorder < A P >: Move the character selection one position up. If 
already at the first line of the text buffer, this command is interpreted as 
backward-preorder, as described in Section I.E.4, provided the text is 
syntactically correct. 

• right < A F >: Move the character selection one position to the right. If already 
at the rightmost character of a line, the character selection advances to the first 
character of the next line of the text buffer. If already at the rightmost character 
of the last line of the text buffer, the command is interpreted as forward-after- 
parse. 

• left < A B >: Move the character selection one position to the left. If already at 
the leftmost character of a line, the character selection advances to the last 
character of the previous line of the text buffer. If already at the leftmost 
character of the first line of the text buffer, the command is interpreted as 
backward-preorder. 

• beginning-of-line < A A >: Move the character selection to the beginning of the 
line. 

• end-of-line < A E >: Move the character selection to the end of the line. 

• forward-after-parse (no key-binding): If textual entry is terminated by 

forward-preorder, then upon successful analysis the forward-preorder 
command is replaced by forward-after-parse. Let t be the subterm or sublist 
that has replaced the selection as a result of textual input. If no existing place- 
holder occurs within t, then forw r ard-after-parse stops at the first resting place 
beyond t. Forward-after-parse never inserts optional placeholders either in t or 
beyond t. 

6. Moving the Locator on the Screen 

The commands described in this section apply only to editors generated for 
standard video display terminals (for editors generated for workstations equipped with a 
mouse, the mouse can be used to point anywhere in the object pane, and clicking the 
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mouse will change the current selection). It is important to note that the locator is 
distinct from the selection. The locator identifies a point on the screen and not a point in 
the buffer (i.e., the locator does not necessarily agree with the selection in the parse tree). 
[Ref. 11: p. 105] 

The following commands move the locator (i.e., the cursor): 

• pointer-left < ESC-b >: Move the locator one character to the left. If already 
in column one of the object pane and not already at the leftmost scroll position, 
scroll the window. 

• pointer-right < ESC-f >: Move the locator one character to the right. If 

already at the right border of the object pane, scroll the window. 

• pointer-up < ESC-p >: Move the locator one character up. If already at the top 
of the object pane and not already at the uppermost scroll position, scroll the 
window. 

• pointer-down < ESC-d >: Move the locator one character down. If already at 
the bottom of the object pane, scroll the window. 

7. Structural Editing 

Structural modifications follow a cut-and-paste paradigm, similar to block-edit 
functions found in many text editors. Only whole, well-formed substructures can be 
removed and inserted. [Ref. 11: p. 108] 

The following commands are used to move, copy, or delete entire subtrees of the 
overall abstract syntax tree: 

• cut-to-clipped < A W >: Move the selection of the current buffer to the distin- 
guished buffer CLIPPED. The removed selection is replaced by a placeholder, 
which becomes the new selection. The previous contents of CLIPPED are lost. 

• copy-to-clipped < ESC- A W >: Copy the selection of the current buffer to buffer 
CLIPPED. The previous contents of CLIPPED are lost. 
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• paste-from-clipped < A Y >: Move the contents of buffer CLIPPED into the 
buffer at the current selection, which must be a placeholder. In CLIPPED, a 
placeholder term replaces the previous contents. 

• copy-from-clipped < ESC- A Y >: Copy the contents of buffer CLIPPED into 
the buffer at the current selection, which necessarily must be a placeholder. The 
contents of CLIPPED are left unchanged. 

• copy-text-from-clipped < ESC- A T >: Copy the contents of buffer CLIPPED, 
as text, into a text buffer at the current selection immediately preceding the 
character selection. The contents of CLIPPED are left unchanged. 

• delete-selection < A K >: Move the selection of the current buffer to the 

distinguished buffer DELETED. The selection becomes a placeholder. The 
previous contents of DELETED are lost. 

8. Textual Editing 

Textual insertion and textual re-editing are permitted for some components of the 
language, as discussed in Section I.E.5 above. 

If a textual insertion is permitted at a placeholder, you merely begin to type; this 
causes the text of the placeholder to disappear and the keystrokes are echoed in the text 
buffer, which is displayed in place on the screen. 

If textual re-editing of an existing structure is desired and is permitted, the 
character selection is positioned at the desired place in the text buffer whereupon the user 
can begin to either type or erase characters. If the current selection was established by 
tree traversal, as described in Section I.E.4 above, then the textual-insertion point is in 
front of the character at which the locator pointed when the select-start was executed. 
[Ref. 11: p. 109] 
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The following commands are used to edit text within the text buffer: 

• delete-next-character < A D >: Delete the current character selection. If the 
character selection is at the end of a line in the text buffer (other than the last 
line), then the current line and the next line are joined into one line. 

• delete-previous-character < DEL >: Delete the character to the left of the 
character selection. If the character selection is at the beginning of a line in the 
text buffer (other than the first line), then the current line and the previous line 
are joined into one line. 

• erase-to-end-of-line < ESC-d >: Erase from the character selection to the end 
of the line, including the character selection. 

• erase-to-beginning-of-line < ESC-DEL >: Erase from the beginning of the line 
to the character selection, not including the character selection. 

• delete-selection < A K >: Delete the entire line. 



F. SAMPLE EDITING SESSION 

We present a sample editing session using the standard video display terminal version 
of SPECDEF. We will create a small specification file, save it for later re-editing, recall 
the file into the editor, modify it, and save it for printout. 

Some terminology that is used throughout the remainder of this section needs to be 
clarified: 

• Recall that a phylum can be thought of as a node in the abstract syntax tree. 

• A completing term is the default representation of a phylum. Completing terms 
can be replaced through template transformations, if any are enabled. The 
completing term for some phyla are user prompts, consisting of the phylum name 
enclosed in angle brackets, e.g., <formal_parm>. Other phyla have template 
patterns with keywords for the respective phylum. 

• A placeholder term is also a default representation of a phylum. For non- 
optional phyla, the placeholder term is identical to the completing term. But for 
phyla that are declared as optional, the placeholder is usually a user prompt, as 
described above, indicating where a transformation can be inserted if desired. 
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In the diagrams that follow, recall that text that would appear as highlighted text on 
an actual video display is printed in boldface. 

We invoke the editor by typing SPECDEF at the Unix prompt with no arguments, as 
we will be creating the specification in this editing session. The initial screen presented 
to the user has a blank object pane, as shown in Figure 31. Note that the help pane 
indicates the selection is positioned at phylum Start. 




Figure 3 1 

Initial Display Screen 



There are no template transformations enabled for phylum start, so we simply 
advance the selection by executing forvrard-with-optionals < A M or RETURN >. After 
depressing the RETURN key, we are presented with the display as shown in Figure 32. 
Phylum spec is declared as an optional list phylum, since we may have zero or more 
occurrences of this construct according to the Spec grammar. Therefore, what we see in 
the display is the placeholder term for phylum Spec, which happens to be the completing 
term for phylum module, the first argument for phylum spec. 
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Figure 32 

Advancing the selection to phylum spec 



As we advance the selection by executing forward-with-optionals < A M or 
RETURN > repeatedly to cycle through phyla module, interface, and formal_name, 
the only changes that occur to the display screen are the name of the current selection 
listed in the help pane, and the disappearance of the highlighting of the keywords 
DEFINITION and END as the selection reaches interface. The next selection is 
identifier, at which point we decide to enter the name of our module, 
waiting_passenger, as shown in Figure 33. 




Figure 33 

Entering text at node identifier 
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The text entry is terminated by entering a carriage return. This causes the entered text 
to be checked for syntactic correctness; it is accepted and inserted in the abstract-syntax 
tree at the node for phylum identifier. The selection is advanced to formal parameters, 
as shown in Figure 34. 

Here we have the first occurrence of a completing term/placeholder tenn/user prompt, 
the string <formal_parm>, to prompt the user that some acceptable form of formal 
parameters should be entered here. We also have two template transformations enabled 
named empty and fieldlist. In this case we do not want any formal parameters, so we 
invoke the transformation empty by first executing execute-command < A l or TAB >; 
when we depress the TAB key, the prompt COMMAND: appears on the command line. 
We only need to enter enough letters of the transformation name to make our choice 
unambiguous; in this case, simply typing e is sufficient to differentiate between empty 
and fieldlist. After typing the e, the screen appears as in Figure 35. 



Current buffer : main 




DEFINITION waiting passenqer<formal_parm> 




END 




Positioned at formal_parameters empty 


fieldlist 



Figure 34 

Display after parsing the module name 
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Current buffer : main 


COMMAND: e 


DEFINITION waiting passenoer<formal parm> 




END 




Positioned at formal_parameters empty 


fietdlist 



Figure 35 

Invoking template transformation empty 



Any of the several commands that move the selection will terminate the template 
command. We use forward-with-optionals < A M or RETURN >. The template for an 
empty formal_parameter list is executed, which replaces the placeholder term 
<formal_parm> with a null. 

The selection is advanced, and the optional phylum inherits is selected. Since this 
phylum is optional, the completing term (a null statement) is replaced on the display with 
the placeholder term, the string <inherit>. There are two INHERIT clauses we wish to 
add, so we invoke execute-command twice, each time typing a for addinherit to display 
the templates for two INHERIT clauses, as shown in Figure 36. Note that the selection is 
still positioned at the <inherit> prompt on the first line, since the abstract-syntax rule for 
inherits insens an instance of inherits at the beginning of each clause until a null clause 
is selected. To get rid of this prompt and advance to the first INHERIT clause, we must 
invoke the transformation empty on the command line. 
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Current buffer : main 




DEFINITION waiting passenger<lnherlt> 
INHERIT <hide><rename> 

INHERIT <hide><rename> 




END 




Positioned at inherits empty 


addinherit 



Figure 36 

After invoking transformation addinherit twice 



After invoking transformation empty, the selection is advanced to actual_name. 
We type in the name elevator, the name of the module we wish to inherit. Even though 
we did not include any actual parameters after the actual name elevator, it is still 
accepted, since actual parameters can be empty. Note that we could have advanced the 
selection one level lower, to phylum identifier, before entering the name elevator, but 
then we would also have had to invoke the transformation for an empty actual parameter 
list and an empty actual argument list. By entering the text at phylum actual_name, we 
have saved some time and effort by not having to bother with the empty parameter and 
argument constructs. Our display now appears as in Figure 37. 

We do not wish to hide or rename any concepts from the inherited module elevator, 
so for each of those selections in turn we invoke the empty template transformation the 
same way we did before. 
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Figure 37 

After entering inherited module name elevator 



Note that after invoking execute-command and entering an e followed by a carriage 
return, the help pane still indicates the selection is positioned at hide ( also the same for 
rename). This is because the hide (rename) that was replaced by a null statement was 
the optional selection that was inserted by the editor when we executed forward-with- 
optionals. When the null statement fills that node, the selection moves back up the 
abstract-syntax tree to the hide (rename) within the template for inherits. By simply 
executing forward-with-optionals < A M or RETURN >, the placeholder <hide> 
(<rename>) is replaced by the completing term (a null statement) and the selection is 
advanced. 

The same process is performed for the second INHERIT clause, with the name 
passenger for the inherited module. Again, we do not wish to hide or rename any 
concepts from the inherited module passenger, so we invoke the empty transformation 
for each of these constructs. 
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The selection is now positioned at imports, another optional phylum. The place- 
holder term replaces the completing term on the display, and our screen looks like that 
shown in Figure 38. 




Figure 38 

Selection positioned at phylum imports 



We do not have any concepts we wish to import, so we invoke the empty trans- 
formation. As we saw with phyla hide and rename, we must execute forward-with- 
optionals after completing the transformation to advance the selection to export. We 
will not export any concepts, so the identical process is performed for export as we did 
for imports. 

The selection is now positioned at concepts, which is declared as an optional list 
phylum. The completing term for the First argument of concepts is displayed, which is 
the prompt <COncept> from phylum concept, as shown in Figure 39. Note that the help 
pane indicates we are positioned at concepts, but we still have two template transfor- 
mations enabled, type and value, which are associated with phylum concept. This 
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feature minimizes the distinction between a singleton sublist and the list item itself, and 
is true for any list phylum. [Ref. 10: p. 67] 

Current butter : main 

DEFINITION waitin g p assenger 
INHERIT elevator 
INHERIT passenger 
<concept> 

END 

Positioned at concepts type value 

Figure 39 

Prompt for entering a concept 

We wish to add a concept that returns a value, so we invoke the execute-command 
command < A l or TAB > and enter v and a carriage return to invoke the value 
transformation. We are presented with the template for a concept that returns a value, as 
shown in Figure 40. 

The selection is positioned at formal_name, the first argument for phylum concept. 
After executing forward-with-optionals, the selection is positioned at identifier. We 
enter the name of our concept, waiting, and are presented with the display as shown in 
Figure 4 1 . 

We do not have any formal parameters, so we invoke the transformation empty. 
However, we do have a single argument to concept waiting. With the selection at 
formal_argumentS, we invoke the transformation fieldlist. This leaves the selection 

positioned at field list with transformation choices single and multiple. We invoke 

transformation single and are presented with the display as shown in Figure 42. 
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Current butler : main 



DEFINITION waitin g p assenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT <formal_args> <where> 
VALUE <formal_args> 

<where> 

END 



Positioned at formal name 



Figure 40 

Template for a concept returning a value 



Current buffer : main 



DEFINITION waiting_passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting<formal_parm><formal_args> <where> 
VALUE <formal_args> 

<where> 



END 



Positioned at formal_parameters 



empty fieldlist 



Figure 41 

Display after entering the concept name waiting 
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Figure 42 

After invoking a single field list 



As we did with actual_name, we will enter the complete text required to make up a 
field, which consists of a namejist and a type_spec. We type p : passenger 
(including the space either side of the colon) and enter a carriage return. Note that we 
could have invoked the transformation namelist, which would have necessitated our 
entering the name_list and type_Spec separately. As before, we elected to enter the 
complete construct at the field node to save time and keystrokes. 

The selection is now positioned at the first <where> prompt, with two transfor- 
mations enabled, empty and addwhere. The display appears as in Figure 43. 
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Figure 43 

After entering the formal argument (p : passenger) 



There is no WHERE clause that applies to the formal arguments, so we invoke 
execute-command, type e and a carriage return to invoke the empty transformation. 
We must also execute forward-with-optionals to remove the <where> prompt and 
advance to the next selection. 

The selection is now positioned at the second occurrence of formal_arguments, the 
prompt <formal_args> after the keyword VALUE. Two transformations are enabled, 
empty and fieldlist. We invoke the fieldlist transformation, which replaces the string 

<formal_args> with (<field>). The help pane indicates the current selection is field list 

with two transformations enabled, single and multiple. We invoke the single 
transformation, and are presented with a screen as shown in Figure 44. Note that the 
completing term/placeholder term for a field (i.e., ? ) has replaced the <field> prompt 
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Current butter : main 



DEFINITION waiting_passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT wa'rting(p : passenger) 

VALUE (?) 

<where> 

END 

Positioned at field namelist collection 

Figure 44 

After invoking the single transformation for field list 

Just as before, we can enter the entire field construct of a name_list and a 
type_spec separated by a free-standing colon. We enter b : boolean and a carriage 
return to fill the field node of the parse tree. 

At this point, we are called away by our boss to a meeting and we wish to save our 
work to resume later. We execute the command write-named-file < A X A W >; a pop-up 
window overlays the bottom of the display screen for us to enter the filename and format 
parameters to the write-named-file command, as shown in Figure 45. 

The selection is positioned at_file_name in the Write File Form window. We type 
in the desired name (including any extension); for this example we choose the name 
waitpass.spec. Just as in the object pane, we terminate text entry by entering a 
carriage return. The selection advances to file_typ© with two transformations enabled. 
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text and structure. The default file format, Structure, is already highlighted in the FILE 
FORMAT : field. If you plan on doing more editing on a file, the recommended format in 
which to save the file is structure. Text format is used to save the display as a printable 
file. Since the default format is the one we want, no further entry is required. To 
complete the execution of the write-named-file command with our selected parameters, 
we must execute start-command < ESC-S >. This causes the command line to echo 
"Wrote waitpass.spec", and the actual file to be written to the file system. 

Current buffer : main 

DEFINITION waiting_passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting(p : passenger) 

VALUE (b : boolean) 

<where> 

END 

—Current Form : Write File Form 

I I 

|WRITE FILE: <flle-name> FILE FORMAT: structure | 

IPositioned at _file_name | 



Figure 45 

Pop-up Write File Form window 

Note that we arc still in the editor. To exit the editor, we simply type A C, which 
deactivates the editor and returns us to the Unix shell. 

To recall our saved file back into the editor for further editing, we have two choices: 
we can include the filename waitpass.spec as an argument to SPECDEF when starting 
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up the editor, or we can start SPECDEF with no arguments and then execute the read-file 
command < A X A R or A X A F >, which will cause a pop-up window to appear, similar to 
the Write File Form window when we saved the file, in which we enter the filename. In 
this example, we choose the former method. 

The initial display this time includes the filename waitpass.spec in the title bar, the 
message "Read waitpass.spec" on the command line, as much of the structure that will 
fit in the object pane (in this case the entire file), and the indication in the help pane that 
we are positioned at Start. Figure 46 shows this display. 



Current buffer : waitpass.spec 



Read waitpass.spec 



DEFINITION waltlng_passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waitlng(p : passenger) 
VALUE (b : boolean) 

<where> 

END 



Positioned at start 



Figure 46 

Reading an existing file into the editor 



There are, again, two choices on how to proceed: we can either advance the selection 
through the entire parse tree using forward-preorder < A N > or forward-with- 
optionals < A M or RETURN >, or we can use end-of-file < ESC-> > to position the 
selection at the rightmost leaf in the parse tree. We choose the latter option to save time, 
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which now positions the selection where we left off during the previous editing session, 
at the second <where> prompt within the construct for concept. 

We invoke the transformation addwhere, which replaces the placeholder <where> 
with the template for a WHERE clause. The selection is advanced to expression_list 
with two transformations enabled, single and multiple. We invoke the single transfor- 
mation, as shown in Figure 47. 

Current buffer : waltpass.spec 

COMMAND: s 

DEFINITION waiting passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting(p : passenger) 

VALUE (b : boolean) 

WHERE <expresslon_l!st> 

END 

Positioned at expressionjist single multiple 

Figure 47 

Invoking the single transformation for expression_list 

The selection is now positioned at expression. In the SPECDEF editor, phylum 
expression has more template transformations available than can be listed in the default 
size of the help pane (4 lines). To be able to see all possible transformation names, the 
help pane must be enlarged by two lines. This is done by executing the enlarge-help 
command < ESC- A Xz > twice, once or each line of enlargement. When this is done, the 
screen will appear as in Figure 48. Notice that many of the transformation names are 
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symbolic rather than alpha-numeric. Note also the completing/placeholder term for 
expression, the symbol ?, which stands for an undefined expression. 



Current buffer : waltpass.spec 



DEFINITION waiting passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger) 
VALUE (b : boolean ) 

WHERE ? 



END 



Positioned at expression 


quantify 


act name 


@ 


- 


& 


1 


implies 


iff 


< 


> 


= 


< = 


>= 


-= 


~< 


-> 


-<= 


*->= 


ass 




uminus 


+ 


- 


* 


/ 


mod 


** 


u 


append 


in_exp 


star 


collect 


range 


dot 


[] 


parens 


measure 


time 


delay 


period 


constant 


lit_type 


illegal 


ifjhen 





Figure 48 

Expanded Help Pane for expression’s transformations 



The expression we wish to enter is a quantified logic expression, so we begin by 
invoking the quantify transformation. The placeholder ? is replaced by the template for 
a quantified expression, as shown in Figure 49. 

We invoke the all transformation, which replaces the placeholder <quantifier> with 

the lexeme ALL and advances the selection to field list. In this example, we want a 

multiple field list, so we invoke the multiple transformation. The resulting display 

appears as in Figure 50. 
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Current buffer : waitpass.spec 



DEFINITION waitin g p assenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger) 

VALUE (b : boolean ) 

WHERE <quantifier>(<field><restriction> :: ?) 
END 



Positioned at quantifier all some number sum product 

set max min union intersect 



Figure 49 

After invoking the quantify transformation for expression 



Current buffer : waitpass.spec 



DEFINITION waitin g p assenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger) 
VALUE (b : boolean ) 

WHERE ALL(<field>,?<restriction> :: ?) 

END 



Positioned at fieldjist single multiple 



Figure 50 

After selecting multiple transformation for field list 



We now address each element of the field list separately. For the first element, 

which is itself a field list, we now invoke the single transformation, which replaces the 

placeholder <field> with the symbol ? and positions the selection at field. 
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As we have done previously, we will enter the entire construct here to save time and 
keystrokes; we enter p : passenger followed by a carriage return. This enters the text 
and advances the selection to the second placeholder for phylum field, the second ?. 
Here we enter f : floor and a carriage return. The selection is now advanced to 
restriction, as shown in Figure 51. 

Current buffer : waltpass.spec 

DEFINITION waiting passenger 

INHERIT elevator 

INHERIT passenger 

CONCEPT waiting (p : passenger) 

VALUE (b : boolean ) 

WHERE ALL(p : passenger , f : floor<restrlctlon> :: ?) 

END 

Positioned at restriction empty suchthat 

Figure 51 

After entering a multiple field list 

We do not have any restrictions on these elements, so we invoke the empty transfor- 
mation. This places the selection at expression following the bind (::) symbol. 

The expression we wish to have apply here is a combination of several "and’d" 
expressions that imply a predicate expression. We start by invoking the & transfor- 
mation. This replaces the ? with the string ? & ?. We are still positioned at expression, 
so we now invoke the actname transformation by executing the execute-command 
command < A l or TAB > and then typing ac, which is sufficient to make our choice 
unambiguous. The first placeholder for expression is replaced by the placeholder 
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<actual_arg>, and the selection is advanced to actual_name. We enter the name of the 
predicate we wish to apply here, waiting. The selection is advanced to 
actual_arguments, with two transformations enabled, empty and arglist. We invoke 
the arglist transformation and are presented with the display as shown in Figure 52. 

Current buffer : waitpass.spec 

DEFINITION waiting passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger) 

VALUE (b : boolean ) 

WHERE ALL(p : passenger , < : floor :: waiting(<arg>) & ?) 

END 

Positioned at argjist single multiple 

Figure 52 

After invoking arglist transformadon for actlial_arguments 

We enter the single argument p. We then advance the selection to expression using 
forward-with-optionals < A M or RETURN >, and invoke the & transformation once 
more. Proceeding similarly to the sequence described above, we enter the various text 
elements until we have built the expression at(p , f). 

Advancing the selection again to expression, we now invoke the implies transfor- 
mation. With the selection positioned at the ? on the left side of the => symbol, we first 
invoke the ~ transformation (the symbol ~ means "not"). Then we proceed similarly to 
the sequence stated previously until we have built the expression —button lit(f). 
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Once more advancing the selection, we now complete the expression on the right side 
of the => symbol until we have built the expression pushes_button(p , f). Our concept 
waiting is now complete, as shown in Figure 53. 



Current buffer : waltpass.spec 



DEFINITION waiting passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger) 

VALUE (b : boolean ) 

WHERE ALL(p : passenger , f : floor 

:: waiting(p) & at(p, f) & -buttonjit(f) => pushes_button(p, f)) 

<concept> 

END 



Positioned at concepts type value 



Figure 53 

The completed concept waiting 



Following a similar procedure, we add a second concept, pushes_button. The 
complete module waiting_passenger now looks like Figure 54. 

We are now' ready to save our module for printout. We invoke the write-named-file 
command < A X A W > as before. The current filename waitpass.spec already fills the 
_file_name field because the filename is associated with the current buffer, so we simply 
enter a carriage return. This time w’e want to save the file in text format so we can print it 
out. We invoke execute-command < A l or TAB > and type t for the text transformation. 
Finally, we execute start-command < ESC-S > to actually write the file. 
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Current buffer : waltpass.spec 



DEFINITION waiting_passenger 
INHERIT elevator 
INHERIT passenger 

CONCEPT waiting (p : passenger) 

VALUE (b : boolean ) 

WHERE ALL(p : passenger , f : floor 

:: waiting(p) & at(p, f) & —buttonjit(f) => pushes_button(p, f)) 

CONCEPT pushes_button(p : passenger, f : floor) 

VALUE (b : boolean) 

END 



Positioned at where empty addwhere 



Figure 54 

The complete module waiting_passenger 



Since we used the same filename as the previously saved structure formatted file, the 
contents of that file are overwritten by the text format of the current buffer. Now we can 
exit the editor by executing the exit command < A C >. 

The file waitpass.spec is now saved as a standard ASCII file that appears the same 
as the display in the object pane. The file can be printed as you would any text file. 

If the reader is still unsure about any of the commands that were used in this sample 
editing session, review Section I.E on the commonly used commands. For a complete 
list of all commands available with full descriptions, see Chapter 3 of The Synthesizer 
Generator Reference Manual [Ref. 1 1 : pp. 90- 1 1 1]. 



149 



APPENDIX D 



LIST OF EDITOR COMMANDS 

The following is a complete list of all the available editor commands for any editor 
created by the Synthesizer Generator. Most of the commands have an associated key- 
binding. Those that don’t have a key-binding are indicated by (none). See Chapter 3 of 
The Synthesizer Generator Reference Manual for a full description of each command. 
[Ref. 11] 



advance-after-transform 


(none) 


advance-after- parse 


(none) 


apropos 


< ESC-? > 


ascend-to-parent 


< ESC-\> 


backward-preorder 


< A P> 


backward-sibling 


< ESC- A P > 


backward-sibling- with-optionals 


< ESC- A B > 


backward-with-optionals 


< A H > 


beginning-of-file 


< ESC-< > 


beginning-of-line 


< A A> 


cancel-command 


< ESC-c > 


column-left 


(none) 


column-right 


(none) 


copy-from-clipped 


< ESC- A Y > 


copy-text-from-clipped 


< A T> 


copy-to-clipped 


< ESC- A W > 


cut-to-clipped 


< A W> 


delete-next-character 


< A D> 


delete-other-windows 


< A X1 > 


delete-previous-character 


< DEL > 


delete-selection 


< A K> 


delete-window 


< A Xd> 


dump-off 


(none) 


dump-on 


(none) 
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break-to-debugger 


(none) 


alternate-unparsing-on 


(none) 


alternate-unparsing-toggle 


< ESC-e > 


end-of-file 


< ESC-> > 


end-of-line 


< A E> 


enlarge-help 


< ESC- A Xz > 


enlarge- window 


< A Xz> 


erase-to-beginning-of-line 


< ESC-DEL > 


erase-to-end-of-line 


< ESC-d > 


execute-command 


< A l> 


execute-monitor-command 


< A X!> 


exit 


< A C> 


extend 


< ESC-( > 


extend-start 


(none) 


extend-stop 


(none) 


ext end-transition 


< ESC-X > 


forward-after-parse 


(none) 


forward-preorder 


< A N> 


forward-sibling 


< ESC- A N > 


forward-sibling-with-optionals 


< ESC- A M > 


forward-with-optionals 


< A M> 


help-off 


(none) 


help-on 


(none) 


illegal-operation 


< A G > 


insert-file 


< A X A I > 


left 


< A B> 


list-buffers 


< A X A B > 


new-buffer 


(none) 


new-line 


< A J> 


next-line 


< A 2> 


next-page 


< A V> 


next-window 


< A Xn > 


page-left 


< ESC-{ > 


page-right 


< ESC-} > 


paste-from-clipped 


< A Y> 


pointer-bottom-of-screen 


< ESC-. > 


pointer-down 


< ESC-n > 


pointer-left 


< ESC-b > 


pointer-long-down 


(none) 


pointer-long-left 


(none) 


pointer-long-right 


(none) 


pointer-long-up 


(none) 


pointer-right 


< ESC-f > 
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pointer-top-of-screen 


< ESC-, > 


pointer-up 


< ESC-p > 


previous-line 


< ESC-z > 


previous-page 


< ESC-v > 


previous- wi ndow 


< A Xp> 


read-file 


< A X A R > 


redraw-display 


< A L> 


repeat-command 


< ESC-r > 


retum-to- monitor 


< A > 


right 


< A F> 


scroll-to-bottom 


(none) 


scroll-to-top 


(none) 


search-forward 


< ESC- A F > 


search-reverse 


< ESC- A R > 


select 


< ESC-@ > 


select-start 


(none) 


select-stop 


(none) 


selection-to-left 


(none) 


selection-to-top 


< ESC-! > 


select-transition 


< ESC-t > 


set-parameters 


(none) 


show-attribute 


(none) 


shrink-help 


< ESC- A X A Z > 


shrink-window 


< A X A Z > 


spill 


(none) 


split-current-window 


< A X2 > 


start-command 


< ESC-s > 


switch-to-buffer 


< A Xb> 


text-capture 


(none) 


undo 


< A X A U > 


alternate-unparsing-off 


(none) 


visit-file 


< A X A V > 


write-attribute 


(none) 


write-current-file 


(none) 


write-file-exit 


< A X A F > 


write-modified-files 


< A X A M > 


write-named-file 


< A X A W > 


write-selection-to-file 


(none) 
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